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Abstract 

This  research  established  a  foundation  for  formalizing  the  evolution  of  Abased  ob¬ 
ject  models  to  theories,  part  of  a  dual  approach  for  formally  extending  object-oriented 
analysis  models  using  the  Z  and  LARCH  languages.  For  the  initial  phase,  a  comprehen¬ 
sive,  consistent,  and  correct  Z  language  parser  was  implemented  within  the  SOFTWARE 
Refinery^-^  Programming  Environment.  The  Z  parser  produced  abstract  syntax  trees 
(ASTs)  of  objects,  thereby  forming  the  basis  for  analyzing  the  similarities  and  differences 
between  the  .Z’-based  and  LARCH-based  object  representations.  The  second  phase  used  the 
analysis  of  the  two  languages  to  identify  fundamental  core  constructs  that  consisted  of 
similar  syntactic  and  semantic  notions  of  signatures  and  axioms  for  describing  a  problem 
domain,  thereby  forming  a  canonical  framework  for  formal  object  representations.  This 
canonical  framework  provides  a  front-end  for  producing  design  refinement  artifacts  such  as 
synthesis  diagrams,  theorem  proving  sentences,  and  interface  languages.  The  final  phase 
of  the  process  demonstrated  the  feasibility  of  interface  language  generation  by  establishing 
an  executable  framework  that  mapped  Z  into  the  Software  Refinery^'*'^  Environment 
to  rapidly  prototype  object-oriented  Z  specifications. 
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Unification  of  Larch  and  ^Based  Object  Models 
To  Support  Algebraically- Based 
Design  Refinement; 

The  ^Perspective 


1.  Introduction 

1.1  Background 

The  evolution  of  technology  has  imposed  a  great  challenge  upon  the  software  devel¬ 
opment  process:  how  to  accurately  and  adequately  specify  a  system’s  desired  behavior. 
The  goal  of  these  specifications  is  the  abstract  description,  independent  of  implementation 
details,  of  the  system’s  functional  behavior  (41:1).  Unfortunately,  many  software  develop¬ 
ment  organizations  are  still  relying  on  informal,  error-prone  techniques  and  the  resulting 
products  do  not  satisfy  the  customer’s  requirements.  Therefore,  in  an  attempt  to  change 
the  existing  mindset  and  produce  unambiguous,  verifiable  system  specifications,  the  soft¬ 
ware  engineering  community  is  researching  the  area  of  formal  methods.  These  methods, 
established  on  provable  mathematical  constructs,  are  powerful  mechanisms  capable  of  ab¬ 
stractly  describing  behavior.  Based  on  set  theory  and  predicate  calculus,  formal  methods 
empower  software  engineers  with  the  same  descriptive  and  analytical  techniques  used  by 
traditional  engineers  while  aiding  in  the  evolution  of  software  engineering  into  a  true  engi¬ 
neering  discipline.  Additionally,  some  formal-based  specifications  can  be  executed  and/or 
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transformed  to  produce  viable  software  components,  which  in  turn  can  be  composed  to 


create  the  desired  system. 

Since  the  realm  of  formal  methods  is  essentially  a  branch  of  applied  mathematics, 
various  notations  or  languages  have  been  developed  to  support  their  application.  The  role 
of  the  notation  is  to  connect  language  expressions  to  a  sound  foundation  in  logic  (10:38), 
while  exploiting  the  descriptive  properties  of  the  underlying  mathematical  system.  These 
formal  specification  languages  describe  the  functionality  of  a  software  system  in  terms  of 
a  particular  state  space,  together  with  a  collection  of  operations  that  act  upon  the  space 
(31:5).  The  operations  can  be  constrained  to  a  range  of  valid  states  through  preconditions 
and  postconditions,  thereby  stating  “what”  the  system  does  and  not  “how”  it  performs 
the  task  (procedural  abstraction)  (12:4).  Various  strategies  of  coupling  a  representative 
notation  with  fundamental  mathematical  objects  have  produced  two  major  perspectives  of 
formal  specification  generation:  theory-based  and  object-based. 

In  a  theory-based  approach,  the  target  system  is  described  using  algebraic  structures 
to  model  its  basic  operators  and  the  equational  properties  of  its  behavior.  The  equational 
identities  or  axioms  demonstrate  how  difiFerent  combinations  of  the  basic  operators  can 
create  a  collection  of  structures  that  satisfy  the  desired  model  (31:4).  Unfortunately,  the 
mathematically  intense  nature  of  this  approach  has  discouraged  many  software  engineers, 
therefore  limiting  its  widespread  use.  In  parallel  with  these  developments,  there  has  been 
a  less  rigorous  extension  centered  around  an  object-based  perspective.  In  this  approach, 
the  target  system  is  modeled  as  a  collection  of  fundamental  objects  characterized  by  their 
intrinsic  properties.  This  method  is  well  suited  for  handling  the  structure  of  a  specification 
but  often  introduces  ambiguity  based  on  individual  interpretations  of  an  object’s  behavior. 
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Regardless  of  this  shortcoming,  the  informality  of  this  process  makes  it  user-friendly  and 
more  easily  accepted. 

In  an  effort  to  benefit  from  both  aspects,  the  research  community  is  investigating  var¬ 
ious  techniques  that  attempt  to  meld  these  two  perspectives.  For  example,  one  proposed 
methodology  is  a  domain-oriented  application  composition  system  being  developed  by  the 
Knowledge-Based  Software  Engineering  (KBSE)  research  group  at  the  Air  Force  Institute 
of  Technology  (AFIT).  The  KBSE  application  composition  approach  uses  object-oriented 
models  developed  from  a  variety  of  modeling  methods,  e.g.,  McCain  (25)  and  Rumbaugh 
(40),  and  transforms  these  models  into  an  object-based  model  within  the  Software  Refinery 
design  and  synthesis  environment.  Written  in  Refine,  a  wide-spectrum,  mathematically- 
based  language,  these  portable  object-based  models  can  be  used  to  produce  executable 
specifications.  The  KBSE  application  composition  system,  known  as  ARCHITECT,  uses 
these  canonical  formal  specifications  to  create  domain-specific  applications.  For  each  com¬ 
posed  application,  ARCHITECT  can  execute  a  prototype,  thereby  providing  a  means  to 
demonstrate  correct  behavior. 

Despite  this  seemingly  tailor-made  composition  method,  this  current  tactic  does  not 
adequately  support  verifiability  using  provable  constructs.  Another  generation  of  applica¬ 
tion  composers  is  needed  to  guarantee  the  soundness  of  future  domain  models.  Applying  a 
systematic  approach  based  on  formal  languages  and  algebraic  specifications  could  provide 
that  guarantee  and  serve  as  a  solid  foundation  for  developing  the  next  generation  appli¬ 
cation  composition  system.  To  that  end.  Figure  1.1  illustrates  the  AFIT  KBSE  group’s 
design  of  a  potential  framework  for  front-end  support  of  a  future  composition  system. 
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Figure  1.1  Formalized  Object  Transformations 


The  proposed  framework  depicts  formalized  object  transformations  through  two  com¬ 
plementary  paths  from  Object-Oriented  Analysis  (OOA)  into  REFINE  object  base  models. 
The  left  path  is  based  on  the  non-executable  Z  (pronounced  “zed”)  specification  language, 
which  is  representative  of  an  object/model-based  approach.  Similarly,  the  right  path  is 
based  on  algebraic  specifications  and  represents  a  theory-based  perspective.  The  frame¬ 
work  also  contains  a  third  unifying  path  between  the  resulting  REFINE  object  models.  Since 
each  side  has  its  foundations  in  mathematical  constructs,  these  resulting  models  should 
theoretically  capture  the  same  behaviors  for  a  specified  domain.  A  unifying  mechanism 
permits  generalized  refinement  of  both  languages  within  a  common  abstract  framework. 
Subsequently,  this  canonical  model  provides  the  basis  for  two  target  phases:  design  re¬ 
finement  and  executability  analysis.  The  former  phase  provides  a  satisfiable  interface  to 


1-4 


the  design  process  through  refinement  of  abstract  specifications  into  concrete  descriptions, 
while  the  latter  phase  permits  specification  demonstration  and  validation  via  an  execution 
framework. 

1.2  Problem 

The  current  domain-oriented  application  composition  approach  permits  the  model¬ 
ing  of  abstract  specification  details.  Problem  complexity  is  adequately  managed  through 
abstraction  and  encapsulation.  However,  this  methodology  does  not  guarantee  correctness 
throughout  the  process,  since  no  verification  of  object  interfaces  (horizontal  and  vertical 
relationships)  is  currently  implemented.  By  definition,  horizontal  relationships  refer  to  the 
interconnection  of  two  units  on  the  same  level  while  vertical  relationships  are  indicated  by 
changing  levels  through  the  refinement  of  units  (13:465).  Since  a  major  goal  of  the  next 
generation  composition  system  is  the  ability  to  formally  map  between  levels  of  abstraction, 
i.e.,  horizontal  and  vertical  structures,  the  formalized  object  transformations  of  Figure  1.1 
represent  a  viable  solution  to  this  problem. 

1.2.1  Problem  Statement. 

Formalize  the  object-based  composition  approach  via  the  transformation  of  Z- 
based  domain  models  into  an  executable  framework,  while  incorporating  a  uni¬ 
fication  with  corresponding  algebraic-based  models. 

1.3  Scope 

This  research  addresses  the  Abased  portion  and  a  merging  of  the  two  individual 
models  into  a  unifying  REFINE  object  base  model,  while  concurrent  research  by  Captain 
Catherine  Lin  addresses  the  algebraic-based  path  (23).  Previous  work  by  AFIT’s  Hartrum 
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and  Bailor  (17)  has  resulted  in  a  methodology  for  formally  extending  OOA  models  using 
portions  of  the  Z  notation.  The  resulting  specification  formalizes  the  domain  model,  but 
the  absence  of  a  compiler  prevents  an  automated  transformation  into  the  Refine  object 
base.  Therefore,  a  major  objective  of  this  research  is  the  initial  development  and  validation 
of  a  comprehensive,  consistent,  and  correct  2^ language  compiler,  correlated  to  the  existing 
OOA  framework.  A  second  objective  focuses  on  the  development  of  a  formal  unifying 
model  based  on  the  structural  similarities  and  differences  of  the  Z  and  algebraic  notations. 
Using  the  unified  model,  the  final  objective  is  the  design  and  implementation  of  an  initial 
execution  framework.  The  design  refinement  tasks,  depicted  in  the  lower  left  portion  of 
Figure  1.1,  will  not  be  addressed  during  this  effort. 

l.Jf.  Sequence  of  Presentation 

The  remainder  of  this  thesis  is  organized  as  follows: 

Chapter  II  provides  a  review  of  current  literature  in  the  areas  of  Z  language  devel¬ 
opment  and  tools,  object  orientation  and  Z,  algebraic  specification  languages,  and  imple¬ 
mentation  of  specifications. 

Chapter  III  presents  the  specific  development  approach  for  an  object-based  Z  to 
Refine  compiler,  which  incorporates  a  unification  with  the  designated  LarcH  algebraic 
specification  language.  Additionally,  the  design  validation  criteria  and  sample  problem 
domains  are  identified. 

Chapter  IV  discusses  the  design,  implementation,  and  validation  of  a.  Z  parser,  in¬ 
cluding  the  Mathematical  ToolKit. 
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Chapter  V  describes  the  design,  implementation,  and  validation  of  a  unified  domain 
model  and  accompanying  parsers. 

Chapter  VI  presents  the  design  and  development  of  an  initial  execution  framework 
for  the  two  source  languages,  Z  and  Larch. 

Chapter  VII  contains  conclusions  about  the  resultant  formalized  transformation  pro¬ 
cess  as  well  as  recommendations  for  future  research. 

Several  appendices  are  included  to  provide  additional  information  concerning  this 
formalized  object  transformation  process.  Appendices  A,  B,  and  C  contain  the  selected 
validation  specifications  and  problem  domains.  Appendix  D  depicts  the  graphical  domain 
model  of  the  unified  core,  while  the  accompanying  REFINE  implementations  of  the  domain 
model  and  the  State  Transition  Table  are  presented  in  Appendices  E  and  F.  Similarly,  the 
graphical  models  of  the  .^'-specific  (U.2ed)  extensions  and  the  representative  Refine  code 
are  contained  in  Appendices  G  and  H,  respectively.  Appendix  I  contains  the  grammars 
for  both  the  core  U.^ed  language  and  the  Unified  version  of  the  Mathematical  ToolKit. 
The  code  for  semantic  analysis,  i.e.,  shorthand  expansion,  is  detailed  in  Appendix  J.  The 
graphical  domain  model  of  the  target  Refine  program  is  contained  in  Appendix  K,  while 
the  accompanying  code  is  in  Appendix  L.  Appendix  M  contains  the  REFINE  implemen¬ 
tation  of  the  initial  execution  framework.  Appendix  N  contains  a  User’s  Manual  for  the 
U.^ed  parser  and  execution  framework  and  a  point  of  contact  from  whom  to  acquire  the 
Refine  source  code  for  both  the  Z  and  U2ed  versions. 
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II.  Literature  Review 


2. 1  Introduction 

This  literature  review  examines  research  and  information  relevant  to  the  design  of 
the  Z-based  object  transformation  process  and  unifying  model  described  in  Chapter  I. 
Since  this  thesis  merges  several  separate,  but  integral  software  engineering  disciplines, 
the  review  involved  an  extensive  gathering  and  evaluation  of  knowledge  for  applicability 
and  usefulness.  Focusing  on  the  previously  established  research  objectives,  the  evaluation 
identified  six  main  topics  of  interest:  .Z  language  development,  Z  tools,  object  orientation 
and  Z,  Z  and  structured  development  methods,  algebraic  specification  languages,  and  the 
implementation  of  specifications. 

2.2  Z  Language  Development 

Z  is  a.  formal  language  used  to  specify  sequential  systems  through  a  model-based 
approach,  whereby  a  system’s  states  and  operations  are  abstractly  represented  by  mathe¬ 
matical  constructs  (62:262).  Using  mathematics  to  model  a  system’s  data  permits  effective 
reasoning  about  its  properties  and  yields  provable  results  or  theories  about  its  behavior. 
The  Z  notation  is  based  on  the  mathematical  disciplines  of  predicate  logic  and  set  theory. 
The  predicate  logic  provides  abstract  descriptions  of  a  system’s  operations  and  their  ef¬ 
fects,  while  set  theory  produces  specifications  that  are  precise,  unambiguous,  concise,  and 
amenable  to  proof  (12:7).  In  addition  to  these  disciplines,  Z  employs  a  schema  calculus  for 
the  systematic  encapsulation  of  a  system’s  static  and  dynamic  aspects.  Delimiting  these 
aspects  via  the  schema  construct  can  reduce  the  complexity  of  the  specification  and  high- 
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light  any  inconsistencies  or  deficiencies.  A  system’s  states  and  operations  are  decomposed 
into  static  and  dynamic  schemas,  respectively,  as  follows  (45:2): 

1.  Static  schemas 

•  The  states  that  a  system  can  occupy. 

•  The  invariant  relationships  maintained  through  state  transitions. 

2.  Dynamic  or  operation  schemas 

•  The  possible  operations  in  a  system. 

•  The  relationships  between  operations’  inputs  and  outputs. 

•  The  state  changes  that  take  place. 

The  model-based  approach  of  the  Z  language  is  dependent  on  the  construction  of 
complex  objects  from  a  collection  of  fundamental  objects  and  their  associated  types.  This 
methodology  demands  that  every  mathematical  expression  in  a  ^  specification  be  given  a 
type  which  determines  a  set  known  to  contain  the  value  of  the  expression  (45:26).  There 
are  essentially  four  basic  objects  and  types  within  the  Slanguage  (31:5): 

1.  Given  sets  and  basic  types  -  The  atomic  objects  of  a  specification,  without  any  given 
internal  structure,  e.g.,  integers  (.Z),  yet  form  the  boundary  of  the  specification. 
These  basic  types  not  only  permit  the  construction  of  the  remaining  three  compound 
types  (see  below),  they  also  provide  the  capability  to  construct  complex,  composite 
objects. 
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2.  Sets  and  set  types  -  Sets  containing  objects  of  a  given  basic  type,  e.g.,  a  set  of 
a  potentially  infinite  collection  of  integers  is  of  type  VZ.  Set  members  may  be 
explicitly  or  implicitly  constructed. 

3.  Tuples  and  Cartesian  product  types  -  These  compound  types  are  generally  called 
A/'-tuples  and  may  be  defined  over  n  sets  where  n  is  greater  than  or  equal  to  2.  Set 
members  may  be  explicitly  or  implicitly  constructed. 

4.  Bindings  and  schema  types  -  Bindings  are  objects  that  map  variable  names  to  values 
within  a  Z  specification,  and  bindings  are  formally  established  by  schemas  (8:190). 
Bindings  are  used  in  the  operations  of  Z  and  implicitly  define  instances  of  schema 
types.  The  type  or  signature  of  a  schema  is  a  collection  of  typed  variable  names. 
Signatures  are  created  by  declarations,  and  they  provide  a  vocabulary  for  making 
mathematical  statements,  which  are  expressed  by  predicates  (45:30). 

All  other  mathematical  objects  used  within  the  Z  language  are  modeled  by  combi¬ 
nations  of  these  fundamental  objects  and  are  formally  defined  in  Spivey’s  Mathematical 
ToolKit  (45).  These  prescribed  operations  on  sets  and  integers  are  generally  regarded  as 
standard  in  Z,  but  any  specifier  is  at  liberty  to  either  define  new  sets  and  operations  or 
rework  existing  definitions.  A  notable  example  is  the  generalization  of  numbers  in  the 
ToolKit  to  include  the  real  numbers,  TZ,  and  the  rational  numbers,  Q,  along  with  the 
existing  integers,  Z  (54)  (53). 

2.2.1  Encapsulation  of  Theories.  As  previously  stated,  the  language  is  generally 
considered  to  be  a  model-based  approach  to  software  specification.  However,  since  theories 
model  a  system’s  behavior  via  axiomatic  definitions  of  the  operations,  the  Z  language  can 
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also  be  considered  an  encapsulation  of  theories  (4).  The  underlying  relationship  between 
the  two  approaches  is  analogous  to  the  relationship  between  an  object  class  (theory-based) 
and  an  instance  of  that  object  class  (model-based).  As  an  instance  possesses  the  same  core 
attributes  as  the  parent  object  class,  similarly,  the  intrinsic  properties  of  the  model-based 
Z  language  embody  the  same  mathematical  foundations  found  in  theory-based  algebraic 
languages. 

2.'2,.2  “Executability”  of  Z.  The  Z  specification  language  is  generally  non¬ 
executable,  concentrating  on  “what”  a  system  does  and  not  “how”  it  performs  the  task. 
The  main  reason  for  its  lack  of  executability  is  caused  by  the  incomplete  computation  of 
some  of  the  standard  set  theory  operators  within  the  appropriate  abstract  domain  (8:185). 
Regardless,  executable  interpretations  of  a  subset  of  the  language  are  desirable  to  extend 
the  usefulness  of  .Z’  as  a  prototyping  language.  A  prominent  example  is  the  interpreter  for 
the  Z  language  (55)  (57)  (58)  (56).  This  tool  is  capable  of  “executing”  a  Z  specifica¬ 
tion,  where  “execution”  is  defined  to  be  the  process  of  establishing  the  values  of  top-level 
variables  that  are  uniquely  determined  when  the  specification  is  satisfied  (58).  Z  has 
its  own  modified  version  of  the  Mathematical  ToolKit  and  attempts  to  maintain  a  sound 
theoretical  basis. 

Unfortunately,  there  are  many  other  ad  hoc  Z  utilities  available  that  do  not  concen¬ 
trate  on  the  notion  of  correctness  but  on  other  factors  listed  below  (8:186). 

•  Efficiency  -  the  speed  with  which  a  result  is  obtained. 

•  Coverage  -  the  portion  of  the  Z  grammar  that  can  be  successfully  handled. 

•  Sophistication  -  the  termination  properties  of  the  technique. 
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These  factors  are  important  to  the  development  of  any  interpreter  or  compiler,  but 
correctness  should  be  the  primary  concern. 

2.3  Z  Language  Tools 

As  formal  methods  like  Z  gain  acceptance  among  software  developers,  the  need  for 
language  support  tools  becomes  apparent.  The  precise  mathematical  syntax  of  Z  facilitates 
the  creation  of  computer-based  tool  sets  for  supporting  the  entire  process  of  formal  spec¬ 
ification  development.  This  process  can  benefit  most  from  tools  that  meet  the  following 
criteria  (50): 

•  Support  writing  specifications 

•  Support  reading  specifications 

•  Prove  properties  of  a  specification 

•  Perform  refinement  of  specifications  into  code 

•  Support  the  Mathematical  ToolKit 

•  Support  large  specifications 

Currently,  there  are  many  different  types  of  Slanguage  tools  available,  all  of  varying 
quality  and  robustness.  As  a  representative  sample,  the  following  sections  summarize  the 
functions  and  capabilities  of  four  widely  used  Z  tools. 

2.3.1  CADIZ.  CADIZ  is  a  UNIX-based  suite  of  tools  designed  to  check  and 
typeset  Z  specifications.  It  checks  for  syntactic,  scope,  and  type  correctness  and  then 
provides  diagnostic  error  reports  that  are  accessible  through  an  interactive  browsing  com- 
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ponent  (50:11).  Through  this  browser,  the  user  can  query  a  range  of  semantic  properties 
that  includes  expansion  of  schemas,  precondition  calculations,  and  simplifications  by  the 
one-point  rule  (26).  CADi^  also  contains  a  proof  editor  that  utilizes  the  second  edition  of 
Spivey’s  Mathematical  Toolkit  in  conjunction  with  the  proof  rules  defined  in  the  Z  Base 
Standard  (Version  1.0)  (9).  The  proof  editor  enables  the  interactive  construction  of  proofs 
through  graphical  proof  trees.  Presently,  an  experimental  extension  (called  Zeta)  for  re¬ 
fining  Z  specifications  to  SPARK  Ada  (a  subset  of  Ada)  programs  is  under  development. 
This  module  produces  the  appropriate  verification  conditions  for  each  refinement  step  and 
then  interfaces  to  a  theorem  proving  tool  (26). 

2.3.2  Formaliser.  Formaliser  is  an  interactive,  single-user  software  tool  that  sup¬ 
ports  editing,  browsing,  and  type-checking  of  formal  languages.  It  accommodates  various 
formal  languages  through  supplied  attribute  grammars  that  specify  the  language  syntax 
and  its  context  conditions.  In  a  specific  application,  Formaliser  supports  the  production  of 
well-formed  Z  specifications  via  building,  editing,  checking,  and  viewing  options.  Structure 
editing  combined  with  “on-the-fly”  parsing  ensures  that  all  Z  documents  developed  within 
Formaliser  are  syntactically  correct  (50:3).  Additionally,  the  tool  displays  mathematical 
symbols  and  constructions  as  they  will  appear  on  the  printed  page  and  supports  interac¬ 
tive  queries  about  scope  and  type  (14:128).  All  specification  documents  are  stored  within 
Formaliser’s  library,  which  permits  the  simultaneous  editing  of  multiple  documents  and 
textual  inclusion  for  linkage  between  documents. 

2.3.3  Z  and  HOL.  The  .^language  is  based  on  set  theory  and  first  order  pred¬ 
icate  logic  and  is  often  used  for  human-readable  formal  specifications,  while  HOL  is  a 
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theorem  proving  environment  for  higher  order  logic  (7:141).  The  Z  and  HOL  system  pro¬ 
vide  lightweight  reasoning  support  for  the  .2^ notation  through  shallow,  semantic  embedding 
within  HOL.  This  shallow  embedding  maps  language  constructs  to  their  semantic  repre¬ 
sentations  in  the  metalanguage,  thus  enabling  reasoning.  This  can  be  contrasted  to  deep 
embedding  which  permits  theorem  proving  through  the  formalization  of  syntax  and 
semantics  within  the  host  logic  (7:160). 

2.3.  J).  ZOLA.  ZOLA  is  a  tool  for  the  creation,  maintenance,  and  verification  of  Z 
specifications.  The  two  modes  for  entering  specifications  are  a  syntax-directed  editor  and 
an  ASCII  parser.  Presumably,  the  former  mode  enhances  familiarity  with  the  Z  syntax, 
while  the  latter  mode  speeds  up  the  editing  process.  The  tool  uses  a  tactical  theorem 
prover  that  implements  the  inference  rules  of  the  logic  as  tactics.  The  application  of 
these  tactics  converts  the  original  goal  into  less  complicated  goals  through  instantiation 
or  term  rewriting  (50:9).  The  current  state  of  the  goals  in  a  proof  is  stored  as  part  of 
the  specification’s  state  and  can  be  extracted  later  for  re-accomplishing  the  proof.  The 
soundness  of  any  theorem  in  a  Z  specification  is  ensured  through  strict  control  of  the 
specification’s  environment,  and  any  changes  made  will  invalidate  the  proven  theorem. 

2.4  Object  Orientation  and  Z 

As  discussed  in  Section  2.2,  the  Z  language  can  specify  state  and  behavior  via  the 
schema  construct.  However,  this  construct  does  not  provide  for  the  grouping  of  opera¬ 
tions  on  a  particular  state,  the  application  of  these  operations  to  different  instances,  or 
the  inheritance  of  these  properties.  Object  orientation  provides  a  method  for  structuring 
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software  and  can  extend  Z  by  including  support  for  classes  and  inheritance.  The  use  of 
objects  divides  up  a  system’s  state  space  into  meaningful  portions,  while  the  inheritance 
of  class  instances  manages  the  system’s  complexity.  Object  orientation  also  offers  support 
for  structuring  large,  complex  systems  through  modularity,  and  for  reuse  of  specifications 
and  proofs  (5:269).  Since  the  inadequacy  of  .^in  these  areas  has  been  well  documented,  the 
pursuit  of  these  benefits  has  produced  two  different  approaches  for  structuring  Z  within 
an  object-oriented  mechanism:  Z  in  an  object-oriented  style  (object-based)  and  object- 
oriented  extensions  to  Z. 

2.4-1  Object-Based  Usage  of  Z. 

2.4.1.1  Hall’s  Style.  The  standard  Z  language  is  capable  of  producing 
descriptions  of  object-like  entities  that  have  states  and  operations,  but  it  cannot  distinguish 
the  individuality  or  identity  of  each  “object”.  Hall’s  Style  of  Z proposes  a  change  to  the  way 
that  basic  state  and  operation  schemas  are  expressed,  whereby  the  state  of  the  individual 
objects  is  extended  to  include  an  explicit  notion  of  self  (59:35).  Different  values  of  the  self 
variable  represent  the  different  identities  of  individual  objects.  For  example,  the  state  of  a 
quadrilateral  is  represented  in  Figure  2.1  (51:20): 

_ Quad _ 

self  :  QUAD 
edges  :  Edges 
position  :  VECTOR 


Figure  2.1  Hall’s  State  Schema 
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The  delta  state  operation  is  also  extended  to  ensure  that  the  self  of  the  quadrilateral 
object  remains  constant,  as  shown  in  Figure  2.2. 

_ QuadOp _ 

AQuad 

self  =  self 


Figure  2.2  Hall’s  Operation  Schema 

This  approach  gives  an  explicit  model  for  the  collection  of  objects  that  comprise  a 
system.  The  system  stores  the  mappings  from  object  identities  to  the  corresponding  object 
states,  and  the  predicates  ensure  that  the  mappings  are  correct.  For  the  purists,  this  Z 
object-oriented  method  is  acceptable,  since  only  the  standard  language  is  used.  However, 
the  flatness  of  the  standard  language  does  not  support  the  object-oriented  notion  of  a  class, 
thereby  limiting  object  compositions  and  also  prohibiting  the  use  of  inheritance  (59:38). 

2.4- 1-2  Z  Expression  of  Refinahle  Objects  (ZERO).  This  methodology  was 
developed  to  address  the  difficulties  that  inhibit  the  refinement  of  large,  formally  spec¬ 
ified  systems.  ZERO  reduces  the  level  of  interaction  between  objects  in  a  large  system 
by  introducing  additional  structuring  into  the  specifications.  Without  significantly  al¬ 
tering  the  standard  Z  notation,  all  objects  are  described  separately  by  export  and  body 
specifications  in  order  to  permit  reasoning  about  them  without  considering  any  internal 
details.  The  export  specifications  algebraically  describe  the  object’s  behavior,  while  the 
body  specifications  describe  its  state  and  methods  (61:29). 
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^RO  includes  intuitive  mechanisms  for  representing  standard  object-oriented  no¬ 
tions  such  as  inheritance,  instantiation,  and  invocation  of  objects  (59:207).  These  mech¬ 
anisms  make  it  possible  for  an  operation  schema  to  refer  to  another  object  by  using  that 
object’s  export  as  a  type  and  then  invoking  methods  on  that  object.  This  facilitates  rea¬ 
soning  about  an  operation’s  results  without  expanding  the  specifications  to  inspect  their 
signatures.  Unfortunately,  this  approach  demands  greater  proof  obligations  between  the 
export  and  body  specifications,  and  it  has  not  been  proven  that  this  definition  of  export 
specifications  will  result  in  a  solution. 

2.4-S  Object-Oriented  Extensions  to  Z.  This  approach  to  combining  object  ori¬ 
entation  and  Z  has  resulted  in  many  different  variations  on  the  theme  of  wrapping  the 
language  within  a  structured  framework.  The  semantics  of  each  approach  are  significantly 
different,  but  the  syntax  is  generally  consistent.  The  common  features  found  in  most  of 
these  object-oriented  extensions  are  (29:81): 

•  The  standard  Z  is  extended  to  allow  the  definition  of  classes,  which  permit  the 
definition  of  the  structure  and  behavior  of  similar  objects. 

•  Classes  can  be  extended  through  inheritance. 

•  Operations  can  be  polymorphically  defined. 

•  The  objects  communicate  through  message-passing. 

The  following  sections  provide  an  overview  of  the  features,  syntax,  and  application 
areas  of  four  Z  extensions:  Object-.^,  Z^^ ,  00.^,  and  MooZ.  These  particular  examples 
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were  chosen  based  on  their  relative  maturity  of  development  and  application  to  substantial 


case  studies. 

2.4-2. 1  Object-Z.  Object-.^  is  an  extension  to  the  language  to  conform 
to  the  constructs  of  object  orientation.  In  addition  to  the  standard  features  such  as  en¬ 
capsulation  and  inheritance,  this  language  also  supports  instantiation,  aggregation,  and 
message-passing.  Most  importantly,  however.  Object- improves  the  clarity  of  large  spec¬ 
ifications  by  addressing  the  problem  of  relating  multiple  state  schemas  to  one  operation 
schema  (38:59).  In  standard  Z,  determining  which  operation  schemas  affect  a  particu¬ 
lar  state  schema  can  only  be  accomplished  by  examining  the  signatures  of  all  operation 
schemas.  Object-.^  overcomes  this  dilemma  by  introducing  a  new  schema  type  called  the 
“class”,  which  acts  as  a  template  for  all  objects  of  that  class.  Each  object’s  states  are 
instances  of  the  class’  state  schema,  and  its  individual  transitions  correspond  to  individual 
operations  of  the  class  (39:11).  A  complex  class  can  inherit  other  classes,  but  each  individ¬ 
ual  class  can  also  be  considered  separately.  The  template  for  an  Object-Z  class  definition 
is  detailed  in  Figure  2.3. 

Within  this  template,  the  visibility  list,  if  included,  restricts  access  to  the  listed 
attributes  and  operations  of  objects  of  the  class.  If  the  visibility  list  is  omitted,  then 
all  features  (the  collective  attributes  and  operations)  are  visible.  In  this  language,  the 
state  schema  is  an  unnamed  Z  schema  which  declares  the  attributes  of  the  class,  while  the 
operation  schemas  use  Z  schema  notation  to  define  state  transitions.  The  history  invariant 
is  a  predicate  over  histories  of  objects  of  the  class,  thereby  restricting  their  behavior. 
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- ClassName  [generic  parameters]  - 

visibility  list 
inherited  classes 
type  definitions 
constant  definitions 
state  schema 
initial  state  schema 
operation  schemas 

history  invariant 

Figure  2.3  Object-.^  Class  Definition 

An  evaluation  of  the  maturity  of  the  language  reveals  that  Object-Z  has  a  well 
developed  theory  of  temporal  logic  specification,  but  it  still  lacks  sufficiently  well-defined 
semantics  for  sequential  specification  aspects.  A  theory  for  refinement  of  the  language  and 
techniques  for  transformation  to  code  (C"'"'')  have  been  developed,  but  the  model  of  time 
is  still  discrete  rather  than  real-time.  Also,  the  language  lacks  an  integrated  approach 
to  the  use  of  informal  notations  with  the  formal  language  notation.  However,  despite  the 
drawbacks,  Object-Zis  considered  to  be  the  most  widely  accepted  object-oriented  extension 
to  the  standard  .^language,  based  on  the  number  of  applications  in  the  language  (19:26). 

2.4-2. 2  Z'^'^ .  The  Z^'^  language  was  developed  as  a  notation  that  could 

naturally  express  designs  and  also  as  a  means  for  correctly  structuring  large  system  spec¬ 
ifications.  Its  syntax  supports  temporal  logic  and  is  therefore  quite  unique;  it  is  different 
from  both  standard  Z  and  the  other  object-oriented  extensions  to  the  language  (20:138).  A 
specification  can  be  composed  of  a  sequence  of  Z  paragraphs  or  Z^~^  class  definitions, 
which  are  more  restrictive.  Additionally,  the  language  permits  class  names  to  be  used  as 
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types,  while  class  methods  can  be  used  as  operations  or  schemas  (21:105).  A  description 
of  a  class  declaration  is  detailed  in  Figure  2.4. 

Object _Class  ::=  CLASS  Identifier  TypeParameters  [EXTENDS  Imported] 

[TYPES  Types]  [FUNCTIONS  Axdefs] 

[OWNS  Locals] 

[RETURNS  Optypes] 

[OPERATIONS  Optypes] 

[INVARIANT  Predicate] 

[ACTIONS  Acts] 

[CONSTRAINTS  Constraints] 

[HISTORY  History] 

END  CLASS 

Figure  2.4  Z'^'^  Class  Specification 

The  semantics  of  Z^'^  are  algebraically-based,  making  it  possible  to  algebraically 
prove  properties  about  a  specification.  Therefore,  category  theory  building  operations 
such  as  product  and  co-product  can  be  applied  to  the  defined  classes  to  achieve  refinement. 
Additionally,  a  model-based  theory  provides  a  method  for  reasoning  about  the  classes  and 
their  refinements.  Some  deficiencies  of  Z'^'^  include  the  forbidding  of  circular  references 
between  classes,  the  lack  of  object  self-reference,  and  the  inability  of  one  object  of  a  class 
to  refer  to  another  object  of  the  same  class  (19:28). 

2. 4-2. 3  Object-Oriented  Z  Environment  ( OOZE).  OOZE  is  a  programming 
environment  that  uses  the  graphical  notation  and  comment  conventions  of  Z,  formalizes  its 
style,  and  adapts  the  language  to  fit  the  object-oriented  paradigm  (2:79).  This  modification 
is  based  on  an  order  sorted  algebra  (vice  the  first  order  logic  and  axiomatic  set  theory 
of  Z),  which  simplifies  reasoning  and  mechanical  verification  of  specifications.  Since  the 
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semantics  are  similar  to  those  of  the  algebraic  specification  language  0BJ3,  it  is  possible 
to  use  term  rewriting  to  execute  certain  00^  specifications.  The  overall  environment 
includes  a  syntax  checker,  a  type  checker,  an  interpreter  for  an  executable  sub-language,  a 
theorem  prover,  and  a  module  database.  The  use  of  generic  modules  enforces  the  notion 
of  encapsulation  through  the  hierarchical  organization  of  specifications. 

In  this  language,  a  clear  distinction  is  made  between  objects,  or  instances,  and  class 
declarations,  which  serve  as  templates  for  the  objects.  The  general  form  of  an  OOZE 
class  specification  is  shown  in  Figure  2.5.  In  this  methodology,  the  initial  values  attribute 
denotes  the  initial  state  of  the  class,  while  methods  defines  the  operations  that  can  affect 
the  attributes  of  a  class.  These  methods  are  written  in  the  conventional  Z  schema  notation, 
and  each  operation  is  constrained  by  a  precondition,  which  must  evaluate  to  true  in  order 
for  the  state  variable  updates  to  occur  (19:24). 

_ Class  class-name  <  ancestor-names  _ 

constants 


methods 

Figure  2.5  OOZE  Class  Specification 

The  00^  language  contains  another  structuring  concept  called  the  module.  A 
module  is  used  to  encapsulate  all  classes  that  have  interdependent  relationships,  or  to 
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group  related  specification  components.  A  particular  form  of  module,  called  theories, 
provides  a  method  for  stating  the  properties  of  class  parameters.  Theories  can  also  be 
parameterized  in  addition  to  using  and  inheriting  other  theories.  The  general  form  of  a 
theory  module  is  seen  in  Figure  2.6. 

_  theory-name  _ 

types 

axiom-declarations 

axioms 

Figure  2.6  OOZE  Theory  Description 

OOZE  is  considered  to  be  a  “wide  spectrum”  object-oriented  language  based  on 
its  loose  specifications  and  executable  programs  (2:94).  The  use  of  loose  specifications  is 
generally  regarded  as  a  powerful  semantic  type  system,  and  executable  prototyping  permits 
the  demonstration  of  the  specified  behavior.  These  characteristics  of  OOZE,  coupled  with 
support  for  re-usability  and  the  reduction  of  complexity,  make  this  environment  well-suited 
for  the  formal-based  development  of  large  software  systems. 

2. 4-2. 4  MooZ.  The  goal  of  the  Mo o^  language  is  to  provide  support  for 
the  object-oriented  design  and  management  of  very  large  specifications.  It  is  considered 
to  be  similar  to  Object-^,  although  its  semantics  are  actually  much  simpler.  A  Moo.^ 
specification  is  a  set  of  hierarchically  related  classes  with  objects  as  values  whose  types  are 
classes  (29:80).  A  bottom-up  structure  is  inherent  in  the  language  based  on  classification 
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and  inheritance  mechanisms.  All  subsystems  are  properly  encapsulated,  clarifying  the 
behavior  of  whole  systems  as  the  interaction  of  its  defined  classes. 

The  general  outline  of  a  Moo.^  class  is  depicted  in  Figure  2.7.  Some  unique  features 
of  this  definition  include  the  givensets,  state,  and  operations  attributes.  Similar  to  “given 
sets”  in  standard  Z  (45),  the  facet  givensets  declares  sets  whose  existence  is  assumed  to 
be  present,  but  no  details  are  defined.  In  Moo.^,  this  feature  permits  the  parameterization 
of  classes.  The  state  facet  describes  the  attributes  of  the  state  of  a  class  and  an  invariant 
or  predicate  expected  to  be  true  for  these  variables  between  invocations.  The  state  is 
described  by  an  anonymous  state  schema  written  in  standard  Z.  The  operations  facet,  also 
written  in  standard  notation,  describes  a  set  of  methods  that  transform  the  state  of  the 
class. 


Class  <.Class-Name> 

givensets  <.type-name-list>- 
superclasses  <class-reference-list> 
<auxiliary-definitions> 
private  <definition-name-list> 
or 

public  <definition-name-list> 
constants  <axiomatic-description-lisf>- 
<  auxiliary-defi  ni  ti  o/js>- 
state  <anonymous-schema>  or  <.constraint> 
■<auxiliary-definitions> 
initialstates  ■<schema> 

■<auxiliary-definitions> 
operations  <definition-list> 

EndClass  -^Class-Namo 

Figure  2.7  MooZ  Class  Definition 


Moo^  uses  a  variation  of  Spivey’s  Z  Mathematical  ToolKit,  where  each  type  con¬ 
structor  is  defined  using  a  generic  class  instead  of  a  set,  thereby  representing  mathematical 
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definitions  as  objects  (28:42).  A  special  superclass  called  MathematicalDefinitions  is  de¬ 
fined  over  all  other  MooZ  classes,  permitting  easy  access  to  all  of  the  ToolKit  definitions. 
Other  distinguishing  features  of  MooZ  are  the  representation  of  objects  as  records  and  the 
treatment  of  schemas  as  messages.  In  comparison  to  the  other  Z  extensions,  MooZ  adheres 
more  to  the  object-oriented  paradigm  than  to  the  semantics  of  the  language. 

2.5  Integrating  Z  and  Structured  Development  Methods 

The  continuous  increase  in  the  size  and  complexity  of  many  software  systems  has 
created  a  demand  for  more  precise  methods  of  capturing  and  specifying  their  desired  be¬ 
havior.  As  a  result,  many  different  types  of  specification  methods  now  exist.  Formal 
languages,  such  as  Z,  are  concise  and  unambiguous  notations  that  permit  reasoning  but 
lack  structure  for  management.  Alternatively,  structured  development  methods,  such  as 
structured  analysis  or  object-oriented  analysis  (OOA),  provide  a  framework  for  managing 
the  size  and  complexity  of  the  specification,  but  they  lack  formality.  The  integration  of 
these  two  methodologies  capitalizes  on  the  individual  advantages  and  produces  software 
specifications  that  are  both  formal  and  problem-oriented  (43:229). 

One  example  of  an  integrated  methodology  is  AFIT’s  formal  extension  of  Rumbaugh’s 
OOA  model  (40)  using  Z  (17).  This  approach  is  detailed  in  Chapter  III  based  on  its 
selection  as  the  starting  point  for  the  formalized  object  transformation  process  described 
in  this  thesis.  As  a  comparison,  a  brief  description  of  a  second  approach  combining  Z  and 
structured  development  methods  is  presented  in  the  following  section. 
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2.5.1  Yourdon  and  Z.  One  example  of  an  integrated  methodology  that  combines 
formal  notation  with  structured  software  development  techniques  is  the  extension  and 
formalization  of  Yourdon’s  structured  analysis  approach  using  the  Z  notation  (43:228). 
This  two-phase  method  uses  the  entity  relationship  diagram  (ERD)  as  the  basis  for  deriving 
the  Z  state  schemas,  while  the  semantics  of  each  of  the  processes  in  the  data  flow  diagram 
(DFD)  are  specified  using  Z  operation  schemas.  This  analysis  produces  an  abstract,  formal 
specification  of  both  the  static  and  dynamic  properties  of  the  target  system. 

The  first  phase,  depicted  in  Figure  2.8,  produces  a  data  model  of  the  system  being 
developed.  This  data  model  is  initially  expressed  as  the  combination  of  an  ERD  and  any 
associated  attribute  lists.  Rectangles  are  used  to  represent  entities,  and  diamonds  are 
used  to  represent  relationships.  The  use  of  the  graphical  ERD  notation  as  the  basis  for  the 
development  of  a  Z  specification  is  well-founded,  since  the  diagrams  have  a  straightforward 
interpretation  in  terms  of  set  theory. 


Figure  2.8  Yourdon  Derivation  of  State  Schemas 


Once  the  ERDs  have  been  completed,  the  discrete  process  of  deriving  the  Z  state 
schemas  is  accomplished  in  four  steps: 


1.  Define  a  basic  type  for  each  attribute,  and  then  define  a  schema  type  to  represent 
the  entity. 
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2.  Define  state  schemas  for  the  instances  of  each  entity  and  any  subtypes.  (Including 
associative  entities.) 

3.  Declare  relations  to  model  the  simple  named  relationships  in  the  ERD. 

4.  Combine  the  entity  and  relationship  schemas  to  provide  a  complete  specification  of 
the  system  state,  adding  predicates  to  constrain  any  relationships. 

The  second  phase,  depicted  in  Figure  2.9,  produces  a  process  model  that  describes 
the  dynamic  behavior  of  the  system.  First,  a  semi-formal  model  is  expressed  using  DFDs 
composed  of  input  and  output  data  fiows,  processes,  and  data  stores.  The  data  flows  are 
represented  as  labelled  arrows,  the  processes  are  circles,  and  the  data  stores  are  parallel 
lines.  The  DFDs  now  represent  the  processing  requirements  of  a  specific  system  as  a  set 
of  data  transformations;  however,  since  the  DFDs  do  not  explicitly  capture  what  each 
process  actually  does,  it  is  necessary  to  provide  a  specification  of  each  transformation’s 
processes.  Using  Z,  it  is  possible  to  write  these  process  specifications  in  an  abstract,  yet 
correct  manner  (43:238). 


Set  of 
Z  Operation 
Schemas 


Figure  2.9  Yourdon  Derivation  of  Operation  Schemas 


First,  all  the  data  in  the  system  is  collected  in  the  data  dictionary,  and  the  exact 
composition  of  the  data  fiows  is  specified.  Then  each  identified  process  is  expressed  as  a 
set  of  one  or  more  Z  operation  schemas  according  to  the  following  guidelines: 
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1.  Use  the  5  convention  if  the  state  is  unaffected  (i.e.  there  are  no  flows  to  any  data 
stores) . 

2.  Use  the  A  convention  if  there  are  any  flows  to  the  data  stores. 

3.  Any  data  stores  not  written  to  can  be  included  in  the  predicate  with  the  0  prefix. 

4.  The  inputs  and  outputs  to  each  operation  schema  can  be  obtained  from  the  content 
of  the  data  flows. 

5.  The  relationships  between  inputs  and  outputs  and  state  changes  are  not  defined  by 
the  DFD  and  must  be  specified  as  preconditions  to  complete  any  operation  schemas. 

The  result  of  this  integrated  methodology  is  a  formal  specification  of  both  the  static 
and  dynamic  properties  of  a  system.  This  approach  retains  the  usability  of  structured 
analysis  and  incorporates  a  mathematically  correct  notation  that  is  both  precise  and  un¬ 
ambiguous.  It  is  currently  limited  in  application  to  information  systems  only,  but  exten¬ 
sions  for  dealing  with  concurrency  are  being  developed.  Additionally,  the  developers  have 
adapted  their  method  to  follow  an  object-oriented  approach  consisting  of  an  information 
model  (ERD)  and  the  corresponding  state  models  (state  transition  diagrams  (STD)).  The 
overall  system  is  then  regarded  as  a  network  of  communicating  state  machines. 

2.6  Algebraic  Specification  Languages 

In  Chapter  I,  two  perspectives  of  formal  specification  generation  were  introduced: 
model-based  and  theory-based.  An  example  of  the  former  perspective  is  the  Z  language, 
which  builds  an  abstract  model  of  a  system’s  states  and  operations.  The  contrasting  theory- 
based  approach  is  represented  by  algebraic  specifications,  which  characterize  a  system  by 
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describing  its  properties  (49:104).  These  languages  are  based  on  the  concept  of  defining 
an  abstract  data  type  (ADT)  as  a  many-sorted  algebra,  which  comprises  one  or  several 
sets  of  values,  called  sorts,  and  operations  on  these  sets  (15:3).  These  sorts  and  operations 
provide  the  basis  for  building  a  theory,  which  captures  three  distinct  facts  about  the  ADT: 

1.  Signature  -  A  listing  of  the  sort  names,  operation  names,  and  the  applicable  domains 
and  co-domains  of  these  operations.  The  signature  forms  a  domain  vocabulary  for 
the  specification. 

2.  Axioms  -  The  logical  formulas  generated  by  the  signature’s  vocabulary.  The  axioms 
constrain  the  operations  and  must  be  satisfied  by  the  underlying  algebras.  Deriva¬ 
tions  from  the  types  of  axioms  used,  e.g.,  equations,  Horn  clauses,  or  first-order  logic, 
determine  the  presentation  of  the  theory  (49:94). 

3.  Models  -  These  are  the  algebras  denoting  a  set  for  each  sort  and  a  function  or  relation 
for  each  operation.  The  behavior  of  these  models  must  satisfy  the  specified  axioms. 

The  variety  of  logics  used  for  defining  axioms  has  produced  many  different  algebraic 
specification  languages.  Some  of  the  more  representative  languages  and  their  underlying 
logics  and  semantics  are  described  in  the  paragraphs  below. 

2.6.1  ACT  ONE.  ACT  ONE  is  a  kernel  specification  language,  restricted  to 
basic  algebraic  data  type  specifications  and  their  structuring  mechanisms.  Coupled  with 
equational  logic  and  denotational  semantics,  these  factors  actually  limit  descriptive  power 
and  prohibit  “loose  specifications”,  that  is,  multiple  variable  bindings  that  satisfy  global 
specification  properties  (62:270).  Its  theory  building  operations  include  combine,  rename, 
and  actualize.  The  combine  operation  produces  the  union  of  specifications  and  permits  the 
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sharing  of  data  when  used  in  conjunction  with  the  renaming  operation.  The  actualization 
operation  provides  for  the  instantiation  of  parameters.  ACT  ONE  supports  a  structuring 
methodology  based  on  hierarchy  and  abstraction.  Hierarchies  are  realized  by  the  extension 
of  the  ADTs,  while  stepwise  refinement  is  used  to  add  details  to  the  original  abstraction 
(11:370).  Since  ACT  ONE  is  limited  in  its  ability  to  handle  large  specifications,  an  ex¬ 
tension  to  the  language  is  under  development.  The  successor,  ACT  TWO,  supports  both 
horizontal  structuring  through  interconnection  of  modules,  and  the  vertical  structuring  of 
systems. 

2.6.2  Clear.  Clear  also  uses  equational  logic  but  instead  couples  it  with  loose 
semantics.  This  makes  the  language  more  robust  than  ACT  ONE  as  theories  may  be 
shared  while  the  building  operations  remain  independent.  More  complex  theories  can  be 
built  either  through  the  coproduct  of  shared  theories  or  the  enrichment  of  an  existing  theory 
with  new  sorts,  operations,  and  equations  (48:97).  CLEAR  can  also  force  the  particular 
interpretation  of  a  theory  through  the  derive  operation.  The  power  of  the  language’s 
semantics  is  based  in  a  body  of  mathematics  called  category  theory  (62:271). 

2.6.3  OBJ.  OBJ  is  an  executable  algebraic  specification  language  that  is  based 
on  order-sorted  logic  and  both  denotational  and  operational  semantics.  The  executability 
of  the  language  forces  the  extra  constraints  of  termination  and  uniqueness  on  any  rewrite 
rules  (62:271).  An  OBJ  specification  has  a  hierarchical  structure  whose  top-level  entries 
include  objects,  theories,  and  modules.  The  language  uses  an  IMAGE  construct  as  a  means 
of  instantiating  reusable  generic  objects  from  an  original  object.  An  object  introduces  one 
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or  more  sorts  represented  by  various  identifiers  that  denote  the  carrier  set  of  the  sort  and 
operations  and  their  signatures. 

2.6.4  Larch.  The  Larch  language  is  based  on  equational  logic  and  predicate 
calculus  for  its  semantics  (62:272).  It  is  uniquely  designed  to  take  a  two-tiered  approach 
to  specification  through  a  shared  language  and  a  set  of  interface  languages.  The  Larch 
shared  language  (LSL)  describes  objects  by  using  theories  that  are  free  of  implementation 
details.  Additionally,  the  LSL  is  accompanied  by  a  library  of  specifications  and  specifi¬ 
cation  components,  which  define  many  basic  concepts,  e.g.,  stacks  and  sets.  The  set  of 
interface  languages  permits  the  enrichment  of  shared  language  theories  to  reflect  final  im¬ 
plementation  structures.  An  interface  is  specified  using  a  syntax  that  parallels  the  target 
programming  language. 

2. 7  Implementation  of  Specifications 

The  construction  and  implementation  of  reliable  and  correct  software  systems  from 
their  specifications  is  often  complex  and  imprecise.  In  program  development,  the  design 
stage  of  the  software  lifecycle  bridges  this  gap  between  specification  and  implementation 
through  various  transformations  or  refinements  that  incorporate  details  in  manageable 
increments.  The  increments  can  be  formalized  into  frameworks  that  enforce  constraints 
throughout  the  transformation,  thus  incorporating  a  correctness-preserving  quality.  Two 
examples  of  specification  implementation  approaches  are  discussed  below. 

2.7.1  Transformational  Programming.  The  first  approach  to  the  implementation 
of  formally  specified  software  is  the  integration  of  formal  methods  with  transformational 
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programming.  This  methodology  of  program  construction  is  based  on  successive  applica¬ 
tions  of  transformation  rules  to  a  formal  specification  in  order  to  produce  an  executable 
program  (33:201).  Transformation  rules  are  partial  mappings  between  the  various  versions 
of  the  program  such  that  the  relationship  between  an  element  of  the  domain  and  its  im¬ 
age  constitutes  a  correct  transformation.  This  correctness-preserving  quality  is  achieved 
through  predicates  that  constrain  the  program  scheme. 

Transformation  rules  can  be  represented  in  two  ways:  procedural  rules  or  schematic 
rules.  Procedural  rules  are  often  referred  to  eis  global  or  semantic  rules  and  consist  of  flow 
analysis,  consistency  checks,  and  representations  of  programming  techniques,  e.g.,  divide 
and  conquer  (33:203).  Schematic  rules  are  typically  used  in  connection  with  local  rules 
and  perform  the  following  functions: 

1.  Relate  language  constructs  (syntactic  rules). 

2.  Describe  algebraic  properties  relating  different  language  constructs. 

3.  Express  domain  knowledge  as  data-type  properties. 

Additionally,  two  hybrid  rules,  FOLD  and  UNFOLD,  are  used  to  represent  implemen¬ 
tation  rules.  Their  inverse  relationship  provides  great  flexibility  in  program  development 
through  re-usability  for  whole  classes  of  problems  (34:9).  Therefore,  the  entire  spectrum 
of  transformation  rules  comprises  these  three  types  (procedural,  schematic,  hybrid),  but 
most  systems  extend  this  set  through  supplemental  advice  on  how  to  apply  them.  Some 
examples  of  the  typical  application  options  and  their  purposes  are  listed  below  (33:204): 

•  Enabling  conditions  -  guarantee  correct  application 
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•  Strategic  conditions  -  focus  on  a  specific  goal 


•  Continuation  information  -  suggests  rule(s)  to  try  next 

•  Scope  of  application  -  points  out  other  rule  possibilities 

Transformational  programming  is  used  to  achieve  a  variety  of  distinct  software  devel¬ 
opment  goals.  These  goals  include  general  support  for  program  modification,  program  syn¬ 
thesis,  program  adaptation,  and  program  explanation  (34:11).  Additionally,  this  paradigm 
supports  the  fundamental  software  engineering  attributes  of  efficiency,  portability,  and  re¬ 
usability.  But  its  biggest  contribution  is  in  the  area  of  producing  safe,  reliable,  and  correct 
software  from  formal  specifications. 

5.7.2  Refinement.  Another  approach  to  the  implementation  of  software  specifi¬ 
cations  is  the  process  of  refinement.  Refinement  is  a  technique  that  executes  each  design 
decision  by  incorporating  the  new  information,  through  a  series  of  formally  provable  steps, 
into  a  new  version  of  the  specification.  These  steps,  or  refinement  rules,  demonstrate  the 
satisfaction  relations  between  the  successive  versions  of  the  specifications  (60:5).  Since  any 
mistakes  will  be  reflected  as  failures  in  the  satisfaction  relation,  this  type  of  proof  reduces 
doubt  about  the  specification’s  validity  and  verifies  its  interpretation. 

The  refinement  process  adds  extra  detail  to  each  specification  through  either  data 
or  operation  reification.  The  reification  process  is  defined  as  the  mapping  of  abstract  in¬ 
formation  into  a  more  concrete,  or  machine-processable  state.  The  specific  aim  of  data 
refinement  is  to  produce  adequate  representations  of  all  the  abstract  types  within  the  spec¬ 
ification.  Adequacy  is  determined  by  the  representative  power  of  the  concrete  syntax;  every 
value  in  the  abstract  type  must  be  retrievable  from  the  concrete  type  (60:7).  Additionally, 
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data  refinement  addresses  which  operations  will  access  the  data  and  establishes  mappings 


to  be  used  during  operation  refinement. 

While  data  refinement  deals  with  the  passive  state  of  the  system,  operation  refine¬ 
ment  concerns  the  active  part  of  the  system.  The  principle  of  proving  that  the  concrete 
operations  do  the  same  thing  as  the  abstract  ones  is  known  as  satisfaction.  This  satis¬ 
faction  constraint  of  operation  refinement  is  complementary  to  the  adequacy  constraint 
of  data  refinement.  Operation  refinement  can  either  augment  implicit  information  in  the 
specification  or  implement  algorithms  capable  of  producing  the  required  postconditions  or 
resultant  properties. 

There  are  two  basic  approaches  to  refinement,  either  by  design  and  proof  or  re¬ 
finement  by  transformation.  In  the  first  approach,  the  verification  of  correctness  is  ac¬ 
complished  through  a  derivation  of  proof  obligations  that  are  subsequently  discharged. 
Interactive  theorem  provers  such  as  HOL  can  be  used  for  the  refinement  proof  system, 
but  little  work  has  been  accomplished  in  the  area  of  generating  proof  obligations  (60:14). 
Variations  on  this  approach  also  include  specification  type  checkers  and  animators,  which 
do  incorporate  some  degree  of  a  correctness-preserving  quality.  The  second  approach,  re¬ 
finement  by  transformation,  has  been  automated  and  is  supported  by  various  tools,  e.g.. 
Software  Refinery.  The  Software  Refinery  development  environment  provides  a  domain  for 
specifying  state  transformations  through  descriptions  of  a  precondition  and  a  postcondi¬ 
tion.  Additionally,  the  REFINE  wide-spectrum  language  provides  constructs  to  implicitly 
introduce  the  appropriate  control  structures  when  required. 


2-26 


Refinement  is  a  viable  solution  for  the  complexity  and  imprecision  of  program  de¬ 
velopment.  Since  the  technique  uses  a  series  of  formally  provable  steps  to  implement 
specifications,  it  provides  some  degree  of  correctness-preservation;  however,  although  it  is 
based  on  a  well  established  theory,  refinement  does  not  scale  easily  to  large  specifications 
nor  does  it  adequately  handle  a  requirement’s  functional  constraints  (60:17).  More  work 
is  needed  to  address  these  drawbacks  and  expand  the  applications  of  this  technique. 

2. 8  Conclusion 

This  compendium  of  information  established  a  three-pronged  knowledge  base  that 

forms  the  foundation  for  this  thesis.  First,  in  order  to  construct  a  viable  .2-based  object 

transformation  process,  the  design  methodology  should  address  issues  of  coverage,  correct- 

* 

ness,  and  adherence  to  an  accepted  standard  form  of  the  language.  Second,  in  terms  of 
execut ability,  an  incremental  approach  provides  manageability  and  facilitates  constraint 
enforcement,  thereby  preserving  correctness.  Third,  the  feasibility  of  constructing  an  ac¬ 
curate  unifying  domain  model  between  Z  and  a  selected  algebraic  specification  language  is 
realized  by  their  common  core  of  fundamental  mathematical  structures. 
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III.  Design  of  a  Formalized  Object-Based  Transformation  Process 
3.1  Introduction 

In  Chapter  I,  the  notion  of  the  next  generation  application  composition  system  was 
introduced  and  an  integral  part,  a  formalized  object-based  transformation  process,  was 
depicted  in  Figure  1.1.  A  major  goal  of  this  future  composition  system  is  the  ability 
to  construct  large  systems  out  of  smaller,  well-founded  pieces  while  formally  mapping 
between  levels  of  abstraction  (4).  Consequently,  the  design  and  development  of  an  internal 
transformation  mechanism  must  strive  for  a  product  which  is  flexible,  extensible,  reliable, 
and  verifiable. 

For  this  research  effort,  the  transformation  mechanism  is  an  object-oriented  Z  to 
Refine  compiler  that  incorporates  a  unification  with  algebraic  specification  languages. 
In  terms  of  functionality,  the  system  is  partitioned  into  four  distinguishable  components: 
Rumbaugh’s  OOA  framework  (40),  a  compiler,  a  unifying  model,  and  a  Refine  execution 
framework.  The  requirements  definition  phase  identified  the  projected  methods  and  tools 
for  all  of  the  components  except  the  unifying  model;  a  final  parameter,  the  target  algebraic 
language,  was  required  for  completion.  Therefore,  as  a  part  of  her  concurrent  research. 
Captain  Lin  analyzed  two  specification  languages,  Obj  and  LARCH,  for  problem  suitability 
and  executability.  Based  on  its  potential  adaptability  to  the  existing  OOA  framework, 
availability  of  support  tools,  and  two-tiered  structure,  Larch  was  selected  as  the  target 
algebraic  language.  (A  complete  discussion  of  the  analysis  can  be  found  in  Lin’s  thesis 
(23).)  With  the  completion  of  this  phase,  the  design  of  the  specified  object  transformation 
process  was  started.  This  chapter  describes  the  selected  development  approach,  the  design 
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validation  criteria,  and  problem  domains  in  Sections  3.3  through  3.5  after  an  overview  of 
the  .Z^based  extension  to  the  OOA  framework. 

3.2  Formal  Extension  of  OOA  Using  Z 

As  discussed  in  Section  2.5,  another  example  of  an  integrated  specification  method¬ 
ology  is  demonstrated  by  AFIT’s  formal  extension  of  Rumbaugh’s  OOA  model  (40)  using 
Z  (17).  The  similarities  to  the  structured  analysis  method  of  Yourdon  are  demonstrated 
by  a  procedural  decomposition  process  and  the  diagrams  that  detail  the  resultant  compo¬ 
nents.  Specifically,  the  Rumbaugh  model  of  a  system  is  composed  of  three  distinct  views: 
an  object  model,  a  dynamic  model,  and  a  functional  model.  These  views  are  represented 
by  entity  relationship  diagrams,  state  transition  diagrams,  and  data  flow  diagrams,  respec¬ 
tively.  As  in  the  previous  Yourdon  methodology,  the  three  phases  of  the  formal  extension 
using  Z  produce  an  abstract,  formal  specification  of  both  the  static  and  dynamic  properties 
of  the  target  system. 

The  first  phase,  depicted  in  Figure  3.1,  generates  the  object  model,  which  identifies 
not  only  the  objects  and  their  attributes,  but  their  relationships  (associations,  aggregations, 
inheritance)  as  well. 


Figure  3.1  Rumbaugh  Derivation  of  Static  Schemas 
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With  some  slight  differences  in  the  ERD  symbology  used  in  the  Yourdon  method,  the 


object  model  is  captured  with  the  graphical  notation.  The  object  model  is  then  formalized 
by  defining  a  Z  static  schema  for  each  object  class.  The  signature  of  the  schema  defines  a 
set-theoretic  type  for  each  object  attribute.  The  predicate  portion  of  the  schema  contains 
the  invariants  on  and  between  the  object’s  attributes,  as  well  as  any  derived  attributes 
(17:12).  To  illustrate  the  object  transformation  process.  Figure  3.2  depicts  an  object 
model  for  a  Traffic  Light  class  while  the  corresponding  Z  schema  is  shown  in  Figure  3.3. 

Traffic  Light 

Main  ;  TCOLORS 
Side  :  TCOLORS 

Figure  3.2  Traffic  Light  Object  Model 

TCOLORS  Red  \  Yellow  \  Green 

_ Traf  ficLight _ 

Main  :  TCOLORS 
Side  :  TCOLORS 

Main  =  Red  V  Side  —  Red 


Figure  3.3  Traffic  Light  Static  Schema 


The  second  phase,  depicted  in  Figure  3.4,  begins  with  the  dynamic  model  and  pro¬ 
duces  a  set  of  state  transition  diagrams  that  captures  an  object’s  individual  states  and  its 
overall  state  space. 
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Figure  3.4  Rumbaugh  Derivation  of  State  Schemas 
For  the  derivation  of  Z  state  schemas,  the  following  steps  are  accomplished: 

1.  Name  each  state  and  define  a  corresponding  Z  state  schema  by  declaring  an  object 
of  the  specified  type  and  including  any  associations. 

2.  Declare  the  partition  of  applicable  state  variables  using  tuple  notation  and/or  mem¬ 
bership  in  the  appropriate  associations. 

3.  Include  a  narrative  description  of  the  behavior  of  an  object  while  in  a  state.  (This 
information  will  be  expanded  in  the  functional  model.) 

4.  Use  the  information  from  the  Z  schemas  to  create  a  state  transition  table  to  formally 
define  all  the  transitions  diagrammed  in  the  STD. 

5.  For  each  object,  generate  a  partial  event  flow  diagram  to  document  the  lines  of 
communication  with  other  objects. 


Continuing  with  the  Traffic  Light  example,  the  following  figures  represent  the  dy¬ 
namic  transformation  process:  Figure  3.5  contains  the  dynamic  model.  Table  3.1  depicts 
the  state  transition  table,  and  Figure  3.6  specifies  the  respective  state  schemas. 
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Car_Detected/Set_Timer(5) 


Timer_Expires/Set_Timer(5) 

Figure  3.5  Traffic  Light  State  Transition  Diagram 


Table  3.1  Traffic  Light  State  Transition  Table. 


Current 

Event 

Guard 

Next 

Action 

MainGreen 

MainYellow 

SideGreen 

SideYellow 

Car-Detected 
Timer-Expires 
Timer_Expires 
Timer Expires 

MainYellow 

SideGreen 

SideYellow 

MainGreen 

Set_Timer(5) 

Set_Timer(30) 

Set_Timer(5) 
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_ M  ainGreen _ 

Traf  ficLight 

Main  =  Green 
Side  =  Red 


_ MainY  ell  ow _ 

Traf  ficLight 

Main  =  Yellow 
Side  =  Red 


_ M  ainRed _ 

Traf  ficLight 

Main  =  Red 
Side  =  Green 


_ SideY  ellow _ 

Traf  ficLight 

Main  —  Red 
Side  =  Y  ellow 


Figure  3.6  Traffic  Light  State  Schemas 

The  final  phase  of  this  approach,  depicted  in  Figure  3.7,  describes  the  operations 
defined  in  the  object  model  and  the  actions  defined  in  the  dynamic  model.  As  in  the  Your- 
don  method,  the  generated  DFDs  capture  the  functional  behavior  of  the  object  through 
required  calculations  or  processes,  including  the  sources  and  sinks  of  all  data.  Z  operation 
schemas  are  then  defined  for  each  leaf  process.  K  an  object’s  attributes  are  unmodified 
by  the  operation,  the  S  convention  is  used,  while  conversely,  the  A  convention  is  used  for 
modified  attributes. 
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Figure  3.7  Rumbaugh  Derivation  of  Operation  Schemas 

Completing  the  Traffic  Light  example,  Figures  3.8  and  3.9  illustrate  a  sample  func 
tional  model  and  its  defined  Z  operation  schema,  respectively. 


Figure  3.8  Functional  Model  for  Resetting  the  Traffic  Light 


_ ResetTraf  ficLighi 

ATraf  ficLight 

Main'  —  Green 
Side'  =  Red 


Figure  3.9  Traffic  Light  Operation  Schema 


3-7 


This  integrated  development  method  permits  a  bottom-up  approach  of  composing 
formal  specifications  in  an  object-oriented  framework.  As  demonstrated,  it  is  similar  to 
the  integration  of  Yourdon  structured  analysis  and  Z.  The  one  drawback  is  the  incomplete 
handling  of  the  generated  state  transition  tables,  and  this  is  presently  being  addressed  by 
the  developers,  Hartrum  and  Bailor. 


3.3  Compilation  Process  Model 

In  Chapter  I,  a  major  objective  of  this  research  was  defined  as  the  development  and 
validation  of  a  .Z  language  compiler,  correlated  to  the  .2^based  OOA  framework.  Therefore, 
the  initial  step  in  this  design  effort  focused  on  defining  a  baseline  model  of  the  compilation 
process.  Standard  convention  dictates  that  a  compiler  is  a  program,  or  set  of  instructions, 
that  reads  a  program  in  one  source  language  and  translates  it  into  an  equivalent  program 
in  a  second  target  language.  This  compilation  process,  depicted  in  Figure  3.10,  has  two 
major  portions:  analysis  and  synthesis  (1:2). 


SOURCE 

PROGRAM 


COMPILER 


/  N 

ANALYSIS 

SYNTHESIS 

INTERMEDIATE 

k.  J 

REPRESENTATION 


TARGET 

PROGRAM 


Figure  3.10  Analysis-Synthesis  Model 


The  analysis  portion  breaks  up  the  source  program  into  its  integral  pieces  and  creates 
an  intermediate  representation.  The  intermediate  form  is  a  compact  version  of  the  source 


3-8 


program  that  eliminates  redundancy  and  ambiguity  while  capturing  an  explicit  model  of 
the  input.  The  synthesis  portion  then  constructs  the  desired  target  program  from  this 
intermediate  representation. 

Based  on  its  inherent  modularity,  this  process  model  provides  a  manageable  frame¬ 
work  for  the  object-oriented  translation  of  the  abstract  source  language  Z  into  the  wide- 
spectrum  target  language  of  Refine.  The  framework  was  further  partitioned  via  the 
inclusion  of  the  following  constraints  within  the  development  process: 

•  Coverage  -  the  portion  of  the  Z  language  successfully  handled. 

•  Consistency  -  the  preservation  of  the  original  specification  as  a  mathematical  object. 

Three  main  areas  of  measurable  consistency,  i.e.,  addressable  through  reasoning  tasks, 
are  listed  below  (35:237): 

1.  Consistency  of  Global  Definitions  -  There  exist  values  for  global  declarations 
that  satisfy  the  global  predicates. 

2.  Consistency  of  the  State  Model  -  There  is  a  state  of  the  general  model  and 
applicable  inputs  that  satisfy  the  initial  state  description. 

3.  Consistency  of  Operations  -  The  calculated  preconditions  of  the  operation  schemas 
do  not  evaluate  to  false. 

•  Correctness  -  the  verification  of  the  originally  specified  behavior. 

Once  these  goals  were  established,  the  design  effort  concentrated  on  the  selection  of 
the  appropriate  development  approach. 
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3-4  Development  Approach 


There  are  many  different  development  strategies  for  implementing  a  software  system, 
e.g.,  evolutionary,  water-fall,  spiral.  Prior  to  selection,  a  strategy  should  be  evaluated  for 
project  suitability  based  upon  the  following  factors  (52:3-15): 

•  Nature  and  application  of  the  program 

•  Projected  methods  and  tools 

•  Required  controls  and  deliverables 

Since  these  factors  map  to  the  framework  and  constraints  discussed  in  Section  3.3, 
the  various  strategies  were  assessed  against  the  defined  foundation.  In  the  outcome,  evolu¬ 
tionary  development  was  deemed  appropriate  for  this  research  effort.  Different  than  proto¬ 
typing  in  terms  of  time  and  effort,  this  strategy  involves  developing  a  fully  operational  and 
documented  initial  product  and  then  successively  developing  more  refined  editions  (52:3- 
16).  The  initial  capability  meets  minimum  essential  requirements  and  is  identified  by  a 
flexible,  modular  structure  that  can  accommodate  future  changes.  Inherent  to  this  strat¬ 
egy  are  the  incremental  demonstrations  of  the  product’s  capabilities,  thus  incorporating 
valuable  feedback  into  the  development  process. 

Using  this  evolutionary  approach,  the  compiler  development  was  separated  into  three 
major  iterations  which  are  detailed  in  Chapters  IV,  V,  and  VI  respectively: 

1.  Analysis  \  -  Z  parser  development  (including  Mathematical  ToolKit) 

2.  Analysis  II  -  Unified  model  development 

3.  Synthesis  -  Execution  framework  development 
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In  terms  of  execution,  a  complete  transformation  of  Z  into  REFINE  was  not  ac¬ 
complished.  Rather,  an  execution  framework  composed  of  consistent  and  demonstrable 
mappings  between  the  source  and  target  languages  was  developed.  The  justification  for 
this  outcome  was  directly  tied  to  the  development  strategy.  As  previously  stated,  the 
fully  operational  initial  product  of  an  evolutionary  development  approach  requires  a  great 
investment  of  time  and  effort.  Since  maximum  coverage  of  the  Z  language  was  defined  as 
an  essential  requirement,  the  development  of  the  parser  in  the  first  evolution  was  indeed 
slow  and  meticulous.  The  added  feature  of  a  separate  Mathematical  ToolKit  amplified 
the  complexity  of  the  task,  but,  more  importantly,  it  produced  a  tool  that  adhered  to  the 
accepted  definition  of  the  language! 

3.5  Validation  Criteria  and  Domains 

Within  this  evolutionary  design  strategy,  two  validation  criteria  were  established: 
preservation  of  the  OOA  models’  properties  and  preservation  of  the  structure  and  meaning 
of  the  Z  language.  In  order  to  satisfy  these  guidelines,  three  distinct  phases  were  used 
to  provide  comprehensive  coverage.  Initially,  using  simple  examples,  informal  testing  was 
conducted  to  assess  each  product’s  success  against  the  predefined  requirements.  For  stan¬ 
dardization  and  comparison,  a  simple,  non-reactive  counter  specification  was  designated 
as  the  common  example  for  both  Z  and  Larch.  For  the  second  phase,  integration  testing 
combined  the  simple  test  cases  into  larger  and  more  sophisticated  examples.  For  each  lan¬ 
guage,  various  representative  examples  from  a  wide  range  of  references  were  used.  A  listing 
of  four  specific  Z  examples  is  provided  in  Section  4.3.1.  In  the  final  phase,  a  feasibility 
demonstration  was  conducted  to  validate  the  entire  formalized  object  transformation  pro- 
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cess.  To  ensure  complete  coverage  of  the  process,  a  reactive  domain  model  with  complete 
object,  dynamic,  and  functional  representations  was  selected,  namely,  the  OOA  rocket  ex¬ 
ample  by  Hartrum  and  Bailor  (17).  For  manageability,  the  smaller  fueltank  domain  was 
identified  as  the  common  benchmark  for  both  languages.  For  reference,  Appendices  A,  B, 
and  C  contain  the  different  validation  specifications. 

3.6  Summary 

This  chapter  detailed  the  formulation  of  an  evolutionary  development  approach  used 
to  design  a  Z  language  compiler  that  incorporates  a  unification  with  the  LarcH  specifica¬ 
tion  language.  Three  essential  constraints  were  identified  as  a  foundation  for  the  develop¬ 
ment  process:  coverage,  consistency,  and  correctness.  These  threads  of  control  guide  the 
three  development  evolutions  detailed  in  Chapters  IV,  V,  and  VI. 
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IV.  Z  Parser  Development 


4.1  Introduction 

In  Section  3.3,  a  two-phase  compilation  process  model  was  introduced  as  a  frame¬ 
work  for  managing  the  development  of  a  robust  compiler  for  the  Z  language.  The  two 
phases,  analysis  and  synthesis,  provide  even  further  internal  modularity  for  handling  the 
task’s  complexity.  Commencing  with  the  analysis  section.  Figure  4.1  depicts  a  logical 
apportionment  into  three  distinct  phases. 


SOURCE 

PROGRAM 


ANALYSIS 


PARSER 


INTERMEDIATE 

REPRESENTATION 


Figure  4.1  Compilation  Analysis  Phase 


The  first  phase,  lexical  analysis,  scans  the  source  program  and  groups  sequences  of 
characters  into  tokens  that  possess  a  collective  meaning.  Next,  the  syntactic  analysis  phase 
groups  tokens  together  to  form  hierarchical  syntax  trees,  which  have  a  recursive  basis.  As 
depicted  in  the  diagram,  the  combination  of  the  lexical  and  syntactic  phases  is  often  called 
the  front-end  or  “parser”.  Finally,  the  third  phase,  semantic  analysis,  checks  the  source 
program  for  meaning  errors  and  gathers  type  information  for  the  subsequent  synthesis 
portion  of  compilation. 
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This  chapter  discusses  the  two  major  evolutions  of  the  Z  parser,  namely  the  core 
language  and  the  Mathematical  ToolKit.  The  analysis,  design,  and  validation  of  each 
evolution  are  outlined  in  Sections  4.3  and  4.4  after  a  brief  description  of  the  DIALECT 
component  of  the  Refine  environment. 

j^.2  The  Dialect  Tool 

The  Dialect  tool  within  Software  Refinery  constructs  an  LALR  (bottom-up)  parser 
that  converts  source  text  into  a  Refine  object  base  representation.  DIALECT  requires  two 
inputs:  a  source  language  domain  model,  which  defines  the  structure  of  the  abstract  syntax 
tree,  and  a  grammar  written  in  a  special  high-level  language  that  is  an  extension  of  Backus 
Naur  Form  (BNF).  BNF  is  a  formalism  used  to  describe  the  syntax  of  a  language  through 
a  sequence  of  rules  (42:3).  A  rule  consists  of  a  left-hand  side  (LHS)  and  a  right-hand  side 
(RHS),  separated  by  a  colon.  The  LHS  consists  of  a  single,  unique  non-terminal  symbol. 
The  RHS  consists  of  a  sequence  of  one  or  more  formulations,  which  are  composed  of  non¬ 
terminal  and  terminal  symbols.  DIALECT  extends  the  BNF  in  two  ways:  it  allows  regular 
expressions  to  be  used  in  the  grammar  productions,  and  it  allows  the  names  of  object 
attributes  to  appear  in  place  of  nonterminals  in  the  productions  (36:5-1).  The  syntax  of  a 
production  takes  this  form: 

(  nonterminal-name  )  ::=  [(  syntax-for-class  )]  (  action  ) 

This  grammar  can  also  include  precedence  and  associativity  information  for  removing  am¬ 
biguities.  Some  of  the  features  of  the  Dialect  grammar’s  syntax  include  (36:5-3): 
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1.  Reserved  words  or  symbols  (literal  text)  enclosed  within  double  quotes. 

2.  Optional  constructs  enclosed  within  curly  braces. 

3.  Set-valued  or  sequenced- valued  attributes  followed  by  one  of  three  regular  operators: 
*,  +,  and  -|— 1-.  Respectively,  these  symbols  represent  the  number  of  elements  within 
the  set  or  sequence:  zero  or  more,  one  or  more,  two  or  more. 

The  domain  model  defined  for  the  source  language  is  composed  of  object  classes  and 
the  relationships  defined  between  them.  The  parser  created  by  Dialect  uses  this  domain 
model  to  directly  construct  an  abstract  syntax  tree  (AST)  without  the  explicit  specification 
of  tree  building  instructions.  Each  node  in  the  AST  represents  a  source  language  object 
class  (the  left  side  of  a  grammar  production  rule).  The  branches  of  the  AST  represent 
the  constructs  from  the  right  side  of  the  production  rules.  These  branches  are  annotated 
with  the  name  of  a  REFINE  structural  attribute  mapping,  which  is  a  relationship  between 
two  objects  in  the  domain  model  (37).  Additionally,  annotation  attributes  such  as  boolean 
values,  can  be  defined  for  specific  objects  as  well. 

4-3  Z  Core  Language  Parser^ 

4.3.1  Domain  Analysis.  In  order  to  define  an  accurate  domain  model  of  the  core 
Z  language,  the  structure  of  the  language  was  analyzed  in  great  detail.  As  the  primary 
reference,  the  1989  version  of  Spivey  (45)  was  used  extensively,  based  upon  its  recognition 
as  the  de  facto  standard  in  the  Z  community  and  its  accessibility  in  this  research  effort.  In 
order  to  validate  the  coverage  capability  of  the  parser,  a  variety  of  specification  documents 

'The  original  Z  language  and  Mathematical  ToolKit  domain  models  and  grammars  described  in  the 
following  two  sections  are  not  included  in  this  document.  The  final  versions,  produced  during  the  unification 
phase  (see  Chapter  V),  are  detailed  in  Appendices  D  -  I. 
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were  identified  as  sample  inputs.  These  examples  provided  an  extensive  sampling  of  Z  lan¬ 
guage  constructs  and  their  myriad  combinations.  Specific  documents  and  their  respective 
sources  are  listed  below: 

1.  A  Data  Dictionary  by  Jia  (18) 

2.  An  Aircraft  Passenger  Listing  by  Lightfoot  (22) 

3.  A  Car  Radio  by  McMorran  (27) 

4.  A  Computer  Network  Online  Monitor  by  Ratcliff  (35) 

In  terms  of  structure,  a  Z  specification  document  consists  of  a  sequence  of  para¬ 
graphs  containing  formal  mathematical  text  interleaved  with  natural  language  comments. 
The  various  paragraphs  gradually  introduce  the  variables,  types,  and  schemas  of  the  spec¬ 
ification  by  building  on  any  preceding  definitions.  This  principle  of  “definition  before  use” 
strengthens  the  vocabulary  of  the  specification  and  extends  the  scope  of  each  element  from 
its  definition  to  the  end  of  the  document  (45:49).  As  a  standard,  the  general  format  of  a 
Z  document  is  as  follows  (22:52): 

•  Introduction 

•  Declaration  of  types 

•  The  state  of  the  system  and  its  invariant  properties 

•  An  initial  state 

•  Operations  and  enquiries  (A  and  E  conventions,  respectively) 

•  Error  handling 

•  Final  versions  of  operations  and  enquiries 
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4-3.2  Correlation  to  the  OOA  Framework.  Section  3.2  discussed  AFiT’s  formal 
extension  of  Rumbaugh’s  OOA  model  using  Z.  In  order  to  correlate  the  parser  to  the 
Z  used  within  the  OOA  framework,  all  paragraphs  were  classified  into  two  major  sub- 
types:  definition  and  schema.  Definition  paragraphs  contain  type  information,  axiomatic 
and  generic  definitions,  global  constants,  and  schema  calculus  expressions.  This  type  of 
paragraph  was  distinguished  from  the  intrinsic  schema  paragraphs  because  they  provide 
supplemental  information  to  Rumbaugh’s  object,  dynamic,  and  functional  models. 

Schema  paragraphs  are  categorized  into  four  distinct  types.  In  addition  to  the  three 
types  of  schemas  (static,  state,  and  operation)  described  in  Section  3.2,  the  Z  parser  was 
designed  to  recognize  event  schemas  that  correspond  to  events  contained  in  the  system’s 
state  transition  table(s).  Although  standard  .^does  not  differentiate  between  schema  types 
at  the  syntactic  level,  the  declaration  of  individual  schema  types  in  this  parser  resolved 
ambiguity  problems  encountered  by  Dialect. 

Each  type  of  schema  paragraph  was  defined  to  have  two  major  components:  a  schema 
name  or  id  and  a  schema  body  construct,  which  is  composed  of  a  declaration  part  and  an 
axiom  part.  Some  specific  attributes  of  these  components  are  as  follows: 

1.  Schema  name  -  A  variable  used  to  designate  a  schema.  Once  introduced,  this  id 
becomes  global  to  the  specification  and  cannot  be  used  in  any  other  context. 

2.  Declaration  part  -  This  portion  of  the  schema  introduces  one  or  more  variables  that 
are  composed  of  a  name  and  a  type.  It  is  a  required  construct  in  all  of  the  schema 
types  except  event  schemas.  The  declaration  part  can  also  contain  references  to  other 
schemas  in  the  form  of  inheritance,  inclusion,  or  A/S  conventions  (see  section  4.3.3). 
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3.  Axiom  part  -  This  portion  of  the  schema  is  required  in  the  event  schema  (default  value 
of  true),  but  optional  in  all  others.  When  present,  it  contains  one  or  more  predicates 
that  describe  properties  or  constraints  of  the  schema  variables.  The  predicates  ensure 
that  meaningless  states  of  the  modeled  system  are  not  permitted. 

Figure  4.2  illustrates  the  hierarchical  structure  of  the  schema  paragraphs: 


Figure  4.2  Z  Schema  Components 
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4-3.3  Major  Object  Classes.  In  addition  to  the  various  types  of  paragraphs 
described  above,  the  Z  parser  also  processes  the  following  major  object  classes  integral  to 
a  specification  document: 

1.  Schema  references  -  This  construct  permits  one  schema  to  import  the  text  of  another 
schema  by  referencing  the  latter’s  name  in  its  declaration  part  (35:40).  There  are 
four  distinct  methods  for  schema  referencing:  inheritance,  inclusion,  and  the  A  and 
E  conventions.  Since  the  actual  mechanics  and  meaning  of  each  type  of  import 
are  unique,  individual  object  classes  were  declared  to  remove  ambiguity  during  the 
future  semantic  analysis  phase.  A  more  in-depth  discussion  of  schema  references  can 
be  found  in  Section  6.2.1. 

2.  Decorations  -  There  are  three  standard  decorations  used  for  describing  operations 
on  abstract  data  types:  the  tick  (’)  for  labeling  the  final  state  of  an  operation,  the 
question  mark  (?)  for  labeling  inputs,  and  the  exclamation  point  (!)  for  labeling 
outputs.  Once  again,  the  distinct  meaning  of  each  decoration  led  to  the  definition  of 
individual  object  classes  to  clarify  any  ambiguities  during  future  semantic  analysis. 

3.  Symbols  -  Four  subtypes  of  symbols  were  identified  as  object  classes:  infix,  prefix, 
postfix,  and  miscellaneous.  In  all  cases,  except  for  the  infix  operators  “=”  and  “G”, 
only  the  applications  of  the  symbols  are  defined  in  the  core  language,  while  the  actual 
symbols  are  defined  in  the  Mathematical  ToolKit  (See  Section  4.4).  Additionally, 
the  core  Z  language  has  a  variety  of  symbols  “built-in”  as  basic  elements.  These 
are  classified  as  the  operators  of  propositional  logic  and  the  schema  calculus  and  are 
explicit  components  of  the  remaining  three  object  classes. 
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4.  Schema  calculus  expressions  -  Schema  calculus  permits  short-hand,  structured  de¬ 
scriptions  of  schema  combinations.  There  are  four  broad  categories  of  combining 
operations:  logical  (-1  ,  A,  V,  =»),  quantifying  (V,  3,  3J,  hiding  (\,  :<)  and  special 
purpose,  such  as  calculating  preconditions  and  sequential  composition  (i). 

5.  Predicates  -  Predicates  are  very  similar  to  the  schema  calculus  expressions  in  their 
usage  of  the  logical  (->  ,  A,  V,  =>)  and  quantifying  (V,  3,  3j)  operations.  Ad¬ 
ditionally,  predicates  can  use  infix  relation  symbols  or  be  simply  “true”  or  “false”. 
A  specifier  is  provided  the  capability  for  distinguishing  between  precondition  and 
postcondition  predicates  via  the  ]ATj}X  “also”  command.  The  pretty-printed  output 
separates  the  two  types  with  a  section  of  whitespace  and  the  AST  attributes  are 
labeled  accordingly  for  further  semantic  analysis. 

6.  Expressions  -  The  core  .^language  has  four  subtypes  of  expressions,  which  range  from 
tuples,  bags,  and  sets,  to  A  and  fx  expressions.  Some  of  the  other  “built-in”  symbols 
include  Power  set  (P),  Cartesian  product  (x),  and  binding  formation  {6). 

4.3.4  Core  Language  Grammar.  As  a  prerequisite  for  building  the  core  grammar, 
a  “style”  was  designated  for  input  files  to  the  compiler.  There  are  many  Z  style  options 
available,  and  their  usage  is  dependent  upon  the  target  operating  environment  and  desired 
output  format.  Since  the  lATgX  typesetting  software  is  widely  used  in  the  AFIT  environ¬ 
ment,  its  zed  style  option  was  selected  eis  the  desired  notation  for  all  input  files  (47).  As 
an  additional  justification,  the  lATjjX  files  required  only  minor  changes  to  interface  with 
the  Refine  environment.  The  two  drawbacks  to  this  choice  were  the  tremendous  amount 
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of  commands  and  mnemonics  required  to  express  the  Z  language,  and  the  work  required 


to  map  these  notations  to  their  corresponding  syntactic  categories  in  an  existing  BNF. 

^.3.5  Validation.  As  stated  in  Section  3.3,  three  constraints  were  levied  upon  the 
compiler  development  process:  coverage,  consistency,  and  correctness.  In  order  to  adhere 
to  these  constraints,  the  validation  of  the  Z  parser  was  accomplished  in  the  following  three 
phases: 

1.  Grammar  Optimization  -  This  phase  consisted  of  resolving  either  shift/reduce  or 
reduce/reduce  ambiguities  reported  during  the  compilation  process.  Shift/reduce  er¬ 
rors  occur  when  the  parser  cannot  determine  whether  to  match  the  next  symbol  in 
one  production  (shift)  or  to  reduce  a  string  to  the  start  symbol  of  another  production 
(36:7-2).  Reduce/reduce  errors  are  generated  when  the  parser  cannot  decide  which 
of  several  reductions  to  perform.  Resolution  options  included  such  actions  as  prece¬ 
dence  re-ordering,  addition  of  parentheses,  and  declaration  of  individual  productions 
instead  of  generic  ones. 

2.  Parsing  of  Source  Programs  -  In  addition  to  the  counter  and  fueltank  validation 
domains,  a  variety  of  comprehensive  inputs  (see  Section  4.3)  were  parsed  as  source 
programs  to  the  compiler.  Since  the  core  language  parser  handles  a  minimal  number 
of  expressions  and  symbols,  only  an  applicable  subset  of  these  specifications  was 
tested.  The  main  objective  of  this  phase  was  to  perform  a  consistency  check  via  a 
comparison  of  the  resultant  programs  to  the  originals. 
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3.  AST  Evaluation  -  Each  generated  AST  was  compared  to  the  structure  defined  in 
the  language’s  domain  model.  This  process  was  especially  useful  in  locating  missing 
attribute  maps,  which  created  disjoint  tree  sections. 

4-4  Mathematical  ToolKit  Parser 

The  second  major  evolution  of  the  compiler  development  process  was  the  addition 
of  the  Mathematical  ToolKit  to  the  validated  core  language  parser.  The  ToolKit  provides 
simplistic  data  types  that  can  be  used  to  describe  and  reason  about  many  different  in¬ 
formation  systems  (45:86).  The  versatility  of  the  standard  Z  language  is  based  on  this 
library  of  mathematical  definitions  implicit  within  every  Z  specification  (see  Section  2.2). 
The  preservation  of  this  underlying  relationship  was  deemed  to  be  the  goal  of  this  evolu¬ 
tion.  Dialect  directly  supported  this  goal  through  a  feature  that  provides  a  grammar 
inheritance  mechanism  between  a  common  base  language  and  variant  dialects.  The  gram¬ 
mar  inheritance  copies  the  local  vocabulary  and  user-specified  productions  from  the  parent 
grammar  to  the  inheriting  grammar  (36:5-20). 

4-4-^  Domain  Model  and  Grammar.  The  ToolKit  domain  model  is  composed  of 
object  classes  defined  as  subtypes  of  objects  contained  in  the  core  language  domain  model. 
There  are  three  major  object  classes  in  the  Mathematical  ToolKit:  symbols,  predicates, 
and  expressions.  Using  an  incremental  building  approach,  the  extensive  number  of  objects 
and  their  corresponding  grammar  productions  were  incorporated  into  the  final  ToolKit 
version.  In  terms  of  structure,  the  abstract  syntax  trees  constructed  by  the  ToolKit  are 
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automatically  appended  to  the  core  language  tree  whenever  a  ToolKit  element  is  processed 
by  the  parser. 

4-4-2  Validation.  The  validation  phases  of  the  ToolKit  parser  were  essentially  the 
same  as  the  phases  for  the  core  language,  except  for  two  notable  points.  First,  in  the  area  of 
optimization,  it  was  more  difficult  to  remove  ambiguities  from  the  ToolKit  grammar.  The 
inheritance  relationship  increased  the  grammar’s  complexity  and  propagated  previously 
nonexistent  errors  from  the  core  language  into  the  ToolKit,  making  resolution  difficult 
and  time-consuming.  Ultimately,  the  final  parser  contained  two  unyielding  reduce/reduce 
errors,  which  upon  testing  did  not  demonstrate  any  miscreant  behavior.  The  second  dis¬ 
tinction  was  in  the  area  of  source  program  parsing.  Since  the  coverage  of  the  combined 
parsers  was  greatly  expanded,  the  complexity  of  the  input  files  was  also  increased. 

4.5  Summary 

This  chapter  detailed  the  design  and  implementation  of  a  robust  and  fully  operational 
Z  language  parser  within  the  REFINE  environment.  This  product  permits  the  scanning  of 
Z  specifications  into  hierarchical  tree  structures  which,  in  turn,  facilitate  a  formal  mapping 
between  the  abstract  source  language  and  the  wide-spectrum  target  language.  It  is  this 
mapping  that  forms  the  solid  basis  for  the  development  of  the  next  generation  application 
system.  The  next  phase  builds  on  this  foundation  through  the  unification  of  the  Z  and 
Larch  (23)  parsers  into  a  composite  Refine  target  model,  outlined  in  Chapter  V. 
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V.  The  Design  and  Implementation  of  a  Unified  Domain  Modef 


5. 1  Introduction 


In  Chapter  I,  two  complementary  paths,  a  set-theoretic,  or  model-based  approach 
and  an  algebraic,  or  theory-based  approach,  were  presented  for  formalizing  object  transfor¬ 
mations  into  the  Refine  object  base.  Figure  5.1  depicts  this  transformation  process  and 
also  shows  a  third  horizontal  path.  This  path  represents  another  transformation  mech¬ 
anism,  one  intended  to  produce  a  unified  model  of  the  designated  formal  specification 
languages,  Z  and  LarcH. 


Figure  5.1  Formalized  Object  Transformations 


In  order  to  automate  a  portion  of  the  first  transformation  process,  both  vertical  paths 
contain  a  step  for  language-specific  compilation.  Providing  an  initial  operational  capability 


^This  chapter  was  co-written  with  Captain  Catherine  Lin.  It  also  appears  in  (23). 
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toward  this  goal,  robust  language  parsers  were  designed  and  implemented.  These  parsers 
generated  similar  structural  representations  (abstract  syntax  trees)  that  established  a  basis 
for  the  preliminary  analysis  and  design  of  a  unified  target  model. 

This  chapter  focuses  on  the  evolution  of  a  Unified  Domain  Model,  whose  aim  is  the 
creation  of  a  single,  cohesive  framework  for  translating  different  source  specifications  into 
a  unifying  abstract  structure.  Four  iterations  define  this  evolution,  and  they  are  detailed 
in  Sections  5.2  through  5.5: 

1.  Evaluation  of  Abstract  Syntax  Trees  (AST) 

2.  Analysis  of  Design  Alternatives 

3.  Development  of  a  Unified  Core  Model 

4.  Development  of  Language  Specific  Extensions 

5.2  Evaluation  of  Abstract  Syntax  Trees 

As  mentioned  in  Section  5.1,  the  parser-generated  ASTs  provided  a  common  focal 
point  for  analyzing  the  structures  of  Larch  and  Z  to  establish  the  design  of  a  unified 
target  model.  This  evaluation  process  was  likened  to  an  electronic  balanced  mixer  circuit. 
Accepting  two  input  frequencies,  a  balanced  mixer  produces  four  outputs:  the  two  original 
frequencies,  the  sum,  and  the  difference.  Considering  the  two  ASTs  as  input,  the  evaluation 
produced  the  originals,  common  core  objects,  and  language  specific  objects,  as  depicted  in 
Figure  5.2. 
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ZASTs 


LARCH  ASTs 


Figure  5.2  AST  Evaluation  Process 

5.2.1  Common  Core  Objects.  The  evaluation  of  the  ASTs  revealed  that  both 
languages  contain  strong  similarities  in  their  conceptual  representations  of  a  specification. 
Both  languages  require  a  set  of  signatures,  axioms,  and  external  references  to  describe  a 
problem  domain.  Larch  uses  operators  with  signatures,  axiomatic  equations,  and  context 
references  in  its  specification  format.  Z  defines  a  specification  using  signatures,  predicates, 
and  schema  referencing.  Even  though  the  syntactical  domain,  or  notations,  diflfer,  the 
semantic  domain,  i.e.,  the  mathematical  foundation,  remains  fundamentally  the  same. 
Consequently,  Table  5.1  identifies  a  set  of  core  objects  extracted  from  both  languages  that 
form  the  unified  domain  model. 

5.2.2  Language  Specific  Objects.  The  AST  analysis  also  revealed  differences  in 
the  way  each  language  characterized  the  common  objects.  For  example,  even  though  the 
ASTs  identify  that  both  languages  contain  a  signature,  a  Z  signature  can  use  specific 
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Table  5.1  LarcH  and  Z  Commonalities 


Unifying  Object 

Larch 

Z 

Theory  Object 

Trait 

Schema  Paragraph 

Theory  Id 

Trait  Id 

Schema  Id 

Theory  Body 

Trait  Body 

Schema 

Theory  Signature 

Introduces  Clause 

Declarations 

Theory  External  Reference 

Context  References 

Schema  References 

Theory  Axioms 

Asserts  Clause 

Axiom  Part 

notions  of  state  transitions,  both  the  before  state  (State)  and  the  after  state  (State’),  while 
Larch  does  not.  Additionally,  the  Z  language  is  capable  of  explicitly  declaring  input  and 
output  variables,  while  LARCH  cannot.  Therefore,  these  variances  required  an  approach 
that  captured  each  language’s  specialization,  yet  preserved  the  core  characteristics. 


5.2.3  A  Framework  for  Language  Inheritance.  One  approach  for  modeling  the 
common  core  objects  and  the  specialized  objects  is  through  language  inheritance.  Lan¬ 
guage  inheritance  establishes  a  notion  of  a  common  base  language  that  is  inherited  by 
various  dialects  (36).  These  dialects  specialize  the  common  language  in  order  to  imple¬ 
ment  language  specific  constructs.  This  approach  seemed  well-suited  for  modeling  the 
specialized  constructs  of  Larch  and  Z  because  each  language  can  be  represented  as  a 
dialect  of  a  common  core  language,  i.e.,  a  mathematically-based  language  composed  of  sig¬ 
natures,  axioms,  and  external  references.  Establishing  this  framework  in  Refine  supports 
the  development  of  a  uniform  interface  for  formalized  object-oriented  models.  The  Refine 
object  base  is  capable  of  representing  inheritance  and  specialization  through  object  classes 
and  subclasses.  Figure  5.3  illustrates  an  example  of  language  inheritance  for  Larch  and 


Z  using  the  unifying  objects  defined  in  Table  5.1. 


Figure  5.3  Language  Inheritance 


5.3  Analysis  of  Design  Alternatives 

Using  language  inheritance  as  a  framework  to  consolidate  the  similarities  and  differ¬ 
ences  between  Larch  and  Z  modified  the  initial  transformation  process  depicted  in  Figure 
5.1.  Instead  of  converging  to  a  unified  model  after  compilation,  the  new  design  focused  on 
unifying  the  two  languages  during  the  parsing  stage.  This  new  process  is  founded  on  the 
common  base  language  established  above  and  is  shown  in  Figure  5.4. 

In  order  to  implement  this  new  design,  two  possible  courses  of  action  were  developed: 

1.  Develop  transformation  programs  for  each  language  to  convert  the  grammars  into 
the  unified  model. 

2.  Refine  the  original  language  grammars  in  order  to  parse  into  the  unified  domain 
model. 
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UNIFIED  AST 


Z  AST  EXTENSION  LARCH  AST  EXTENSION 


EXECUTABLE  PROGRAMS  EXECUTABLE  PROGRAMS 

Figure  5.4  Modified  Transformation  Process 

Since  these  paths  were  significantly  different,  an  in-depth  analysis  was  conducted  to 
select  the  best  candidate.  The  strengths  and  weaknesses  of  each  alternative  are  summarized 
in  Figure  5.5  and  discussed  in  the  two  subsequent  sections. 

5.3.1  Transformation  Approach.  Even  though  the  transformation  approach  de¬ 
creases  the  parser’s  complexity,  the  process  introduces  a  level  of  informality  into  the  uni¬ 
fied  implementation.  This  informality  results  from  relying  on  hand-coded  algorithms  to 
construct  the  unified  model  instead  of  a  more  established  parsing  technique  that  relies 
on  machine-generated  algorithms.  Also,  since  reusable  code  is  essentially  prohibited,  the 
transformation  approach  increases  the  amount  of  transform  specializations  needed  in  the 
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UNIFICATION  APPROACH  ALTERNATIVES 


ADVANTAGES  DISADVANTAGES 


TRANSFORM 

APPROACH 

LESS  COMPLICATED  COMPILERS 

ONE  MORE  LEVEL  OF  TRANSLATION 

MORE  EXECUTION  MODEL  ANALYSIS 

INCREASED  TRANSFORMATION 
SPEOALIZATIONS 

PARSING 

APPROACH 

ONE  LESS  LEVEL  OF  TRANSLATION 

MAY  COMPLICATE  COMPBJERS 

TRULY  COMMON  CORE 

SACRIFICE  WORK  ON  EXECUTION 

MODEL 

POSSIBLE  SET  OF  WELL-DEFINED 

REFINE  ABSTRACTIONS 

Figure  5.5  Unification  Design  Alternatives 


overall  formal  process.  More  importantly,  despite  the  advantage  of  completing  more  analy¬ 


sis  of  the  execution  model,  this  model  does  not  adhere  to  the  desired  correctness  constraint. 


5.3.2  Parsing  Approach.  The  parsing  approach  complicates  the  development  of 
the  formal  language  compilers,  thereby  placing  a  time  constraint  on  performing  a  com¬ 
plete  execution  model  analysis.  But,  this  approach  preserves  each  language’s  syntactical 
structure  in  the  unified  implementation.  By  using  DIALECT  to  accept  both  the  unified 
domain  model  and  each  language’s  surface  syntax,  DIALECT  generates  a  parser  for  Z  and  a 
parser  for  LarCH  that  map  to  the  same  common  core  model.  Since  this  approach  preserves 
each  language’s  syntax,  thereby  fulfilling  the  correctness  requirement,  it  is  the  strongest 
candidate  for  the  unification  implementation. 
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5-4  Development  of  a  Unified  Core  Model 


After  completion  of  the  AST  evaluations  and  approach  analyses,  the  next  iteration 
in  the  evolution  of  the  unified  domain  model  focused  on  the  common  core  objects.  Based 
on  previous  experience  with  the  original  parsers  and  the  sensitivity  of  the  DIALECT  tool, 
an  incremental  strategy  was  adopted  to  reduce  the  overall  complexity  of  this  development 
phase.  Using  the  three  OOA  models  as  increments,  the  following  steps  were  outlined  to 
parse  both  Larch  and  Z  into  the  unified  core: 

1.  Design  a  Unified  Core  Domain  Model 

2.  Map  Language  Commonalities  to  Unified  Core  Syntax 

3.  Implement  the  Core  Domain  Models  and  Grammars 

4.  Compile  and  Validate  Grammars 

The  following  sections  detail  these  steps  and  the  resultant  initial  capabilities  of  the 
“ULarCh”  and  “UZed”  parsers.  The  fully  operational  versions  are  described  in  Section 
5.5. 


5.4-i  Framework  for  the  Unified  Core  Domain  Model.  The  common  object  classes 
identified  during  the  AST  analysis  in  Section  5.2.1  formed  the  basis  for  the  unified  domain 
model.  In  order  to  formally  relate  these  commonalities  and  their  intrinsic  properties,  an 
encapsulating  framework  was  defined.  Comparing  both  Larch  and  Z  at  a  high  level  of 
abstraction,  we  can  generally  characterize  these  languages  as  theory  presentations,  or  sets 
of  statements  used  to  describe  some  problem  domain  (4).  Examples  of  theory  statements 
include  domain  models,  software  systems,  and  formal  specifications.  Since  both  LARCH  and 
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Z  define  a  specification  as  their  top-level  object,  a  corresponding  root  object  in  the  unified 
core  was  defined  as  a  “domain  theory”.  Mapped  to  the  Rumbaugh  OOA  framework,  this 
domain  theory  was  categorized  into  three  distinct  DomainTheoryTypes:  ObjectTheory, 
DynamicTheory,  and  FunctionalTheory.  In  terms  of  multiplicity,  one  object  theory  is 
required,  while  there  may  be  zero  or  more  dynamic  and  functional  theories.  To  complete 
the  domain  theory  framework,  each  theory  type  was  defined  through  identical  aggregate 
components:  a  Theoryld  and  a  TheoryBody.  Figure  5.6  provides  a  graphical  depiction  of 
the  core  framework. 


Figure  5.6  Unified  Core  Domain  Model 
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As  stated  above,  a  complete  cycle  of  design,  development,  and  validation  activities 
was  accomplished  for  each  of  the  domain  theory  types.  Based  on  the  fact  that  every  domain 
theory  must  have  an  object  theory,  the  first  phase  concentrated  on  the  ObjectTheory 
implementation.  The  entire  process  is  detailed  in  the  following  three  subsections.  Since 
the  other  two  phases  for  the  dynamic  and  functional  theories  mirrored  the  first  phase,  their 
development  is  summarized  in  Subsection  5.4.5. 

5.4-2  ObjectTheory  Mappings.  After  establishing  the  core  domain  framework, 
the  ObjectTheory  commonalities  of  Larch  and  Z  were  implemented.  Starting  with  the 
layer  composed  of  the  ObjectTheoryld  and  ObjectTheoryBody  classes,  additional  common 
object  classes  were  identified.  Since  the  ObjectTheoryld  is  a  leaf  node,  no  further  decompo¬ 
sition  was  possible.  The  ObjectTheoryBody,  however,  was  partitioned  into  two  additional 
layers.  The  first  tier  contained  the  ObjectTheoryDeclarations  and  ObjectTheoryAxioms. 
The  second  tier,  containing  SignatureDeclarations  and  ExternalReferences,  resulted  from 
further  decomposition  of  the  theory  declaration  component.  Figure  5.7  illustrates  all  the 
common  layers  within  the  ObjectTheory  class.  Below  these  layers,  the  composition  of  the 
two  source  languages  became  too  divergent,  thereby  requiring  language  specific  extensions. 
These  extensions  are  detailed  in  Section  5.5. 

5.4.3  Implementation  of  Domain  Models  and  Grammars.  The  establishment  of  a 
stable  domain  model  for  the  object  theory  facilitated  the  development  of  the  corresponding 
Refine  code.  The  object  classes  and  associations  in  the  domain  model  mapped  directly 
into  Refine’s  object  classes  and  map  attributes.  Analogous  to  the  development  of  the 
original  Larch  and  Z  parsers,  the  tree-attribute  structure  was  defined  by  using  object 
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Figure  5.7  Object  Theory  Body  Domain  Model 


classes  for  the  nodes  and  the  corresponding  map  attributes  for  the  links.  This  tree-attribute 
hierarchy  guided  the  modifications  for  each  language’s  grammar.  Maintaining  consistency, 
Larch  and  Z  specific  rules  were  carefully  mapped  into  a  target  unified  object  theory 
rule.  In  addition  to  re-naming  terminals  and  non-terminals  to  refiect  the  common  unified 
objects,  the  production  rules  had  to  correctly  map  to  each  formal  language’s  extensions. 


5.^.^  Compilation  and  Validation  of  Grammars.  As  a  direct  result  of  each 
original  grammar’s  rigorous  development,  the  compilation  of  the  unified  grammars  was 
straightforward.  The  majority  of  errors  resulted  from  ill-defined  attributes  connecting  the 
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unified  model  to  the  language  specific  models.  The  validation  process  for  the  unified  parsers 
was  accomplished  in  two  phases:  parsing  of  source  programs  and  AST  evaluations.  Since 
this  iteration  of  the  unified  parsers  was  focused  on  the  object  theory,  just  the  object  models 
of  the  counter  and  fuel  tank  domains  introduced  in  Chapter  III  were  used  as  inputs.  A 
visual  inspection  of  each  domain’s  object  theory  clearly  identified  the  boundary  between  the 
common  object  classes  and  the  specialized  ones.  Traversing  the  two  ASTs,  each  node  was 
inspected  to  verify  the  presence  of  expected  attribute  values.  As  an  additional  confirmation, 
the  ULarch  and  U2ed  ASTs  were  compared  against  their  respective  language-specific 
ASTs.  This  process  verified  the  preservation  of  each  language’s  syntax  and  semantics, 
thus  validating  a  common  framework  for  parsing  Z  and  Larch  specifications. 

DynamicTheory  and  FunctionalTheory  Iterations.  As  stated  in  Subsection 
5.4.1,  the  iterations  for  both  the  dynamic  and  functional  theories  were  symmetrical  to  the 
object  theory  iteration.  The  object  classes  of  TheoryDeclarations,  SignatureDeclarations, 
ExternalReferences,  and  Theory  Axioms  were  all  instantiated  with  instances  of  Dynamic- 
Theory  and  FunctionalTheory.  Complete  graphical  models  are  located  in  Appendix  D, 
while  Appendices  E  and  F  contain  the  corresponding  REFINE  implementations.  For  the 
validation  of  both  theory  types,  the  counter  and  fuel  tank  domains  were  augmented  with 
the  appropriate  dynamic  and  functional  models.  The  confirmation  of  this  stage  baselined 
the  Unified  Core  Model’s  capabilities.  In  order  to  complete  the  functionality  of  these  two 
unified  parsers,  the  final  phase  required  the  addition  of  language  specific  extensions. 


5. 5  Development  of  Language  Specific  Extensions 


Since  the  top-level  hierarchy  of  both  languages  inherited  from  the  common  core 
framework,  the  required  changes  for  the  language  extensions  consisted  of  mapping  each 
specific  syntax  to  the  inherited  core.  Reusing  the  language  specific  objects  and  map  at¬ 
tributes  defined  in  the  original  parsers,  the  only  modifications  consisted  of  re-defining  the 
map  attributes  that  linked  the  core  framework  with  the  language  specific  extensions.  As 
an  example.  Figures  5.8  and  5.9  illustrate  the  ULarcH  and  U.^ed  specific  extensions  of 
the  inherited  SignatureDeclaration  class. 

Although  the  majority  of  changes  for  both  language  extensions  was  similar,  some 
individual  syntax  alterations  were  also  necessary.  Specifically,  for  ULarch,  l^TgX  nota¬ 
tions  were  required  in  the  grammar.  Since  both  LARCH  and  Z  specifications  use  lATgX 
notations,  the  production  rules  of  the  ULarch  grammar  were  changed  to  incorporate  the 
lATjjX  notation  as  well.  Also,  since  there  are  significantly  more  syntactical  units  in  Z  than 
in  Larch,  the  UZed  extension  process  was  compounded.  The  following  list  details  the 
major  tasks  involved: 

1.  Distinction  Between  State  and  Event  Schemas  -  Correlated  to  the  original  parser, 
U.Zed’s  DynamicTheory  object  was  further  partitioned  into  StateTheory  and  Event- 
Theory  subtypes.  Their  internal  structures  were  identical  to  their  parent  object, 
composed  of  declarations,  external  references,  and  axioms. 

2.  Inclusion  of  Definition  Paragraphs  -  As  detailed  in  Section  4.3.2,  the  original  Z parser 
recognizes  two  major  types  of  paragraphs:  schema  and  definition.  The  schema  para¬ 
graph  types  mapped  directly  to  the  unified  object,  dynamic,  and  functional  theories 
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Figure  5.8  Signature  Declaration  -  ULarch  Specific  Extension 
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discussed  above.  The  definition  paragraphs  were  designated  as  another  subtype  of 
DomainTheoryType,  namely  a  DefinitionTheory.  Consequently,  all  subtypes  of  Def- 
InitionTheory  were  successfully  appended  to  the  core  framework. 

3.  Inheritance  of  the  Mathematical  ToolKit  -  In  order  to  create  a  unified  version  of  the 
ToolKit,  the  information  pertaining  to  the  inherited  grammar  was  modified.  Since 
the  ToolKit  is  appended  to  the  core  Z  parser  at  a  low  level,  the  changes  to  the 
UToolKit  were  minimal. 

The  complete  set  of  diagrams  for  the  U.2ed  extensions  are  contained  in  Appendix  G, 
while  the  Refine  code  for  the  domain  model  and  grammar  are  located  in  Appendices  H 
and  I,  respectively.  The  equivalent  ULarch  appendices  can  be  found  in  Lin’s  thesis  (23). 

5. 6  Summary 

Although  the  syntactic  domains  of  the  two  source  languages,  Z  and  Larch,  were 
different,  their  semantic  domains  were  conceptually  the  same.  Both  formal  specifications 
encapsulate  theories  about  a  target  problem  domain  through  sets  of  signatures  and  ax¬ 
ioms.  The  notion  of  language  inheritance  produced  a  framework  for  a  unified  core  domain 
model  and  specialized  language  dialects.  Intuitively,  the  languages’  specializations  should 
be  minimal,  since  they  are  both  founded  on  mathematical  constructs;  however,  during  this 
research  effort,  the  lack  of  a  verifiable  mechanism  for  pattern  matching  and  term  rewriting 
limited  the  depth  of  the  inherited  core  to  a  much  higher  level.  Nonetheless,  the  resultant 
unified  design  does  provide  an  initial  consolidation  of  various  formal  language  represen¬ 
tations,  which,  in  turn,  promotes  reusability  and  prevents  escalation  in  the  number  of 
divergent  execution  models.  Adhering  to  the  predefined  goals  of  completeness,  consis- 
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tency,  and  correctness  resulted  in  a  stable  unified  domain  model  that  formed  the  basis  for 
a  target  execution  framework,  detailed  in  the  next  chapter. 
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VI.  Design  of  a  Formal  Execution  Framework^ 

6. 1  Introduction 

In  Chapter  V,  Figure  5.4  depicted  a  transformation  process  that  produces  an  exe¬ 
cutable  program  from  a  unified  abstract  structure.  To  maintain  consistency,  executable 
code  generated  from  a  formal  specification  requires  a  concrete  target  model.  An  execution 
framework  is  the  initial  step  toward  building  this  target  model  because  it  identifies  the  exe¬ 
cutable  program’s  data  structures  and  functions.  The  existing  ULarch  and  UZed  parsers 
provide  the  syntactical  basis  for  this  execution  framework,  but  additional  semantic  analysis 
is  required  to  ensure  consistency.  Therefore,  this  chapter  elaborates  the  steps  necessary  to 
complete  the  compilation  analysis  phase  (refer  to  Figure  4.1)  and  then  describes  the  design 
and  development  of  an  execution  framework.  The  specific  tasks  are  outlined  below: 

1.  Semantic  Analysis 

2.  Creation  of  an  Execution  Domain  Model 

3.  Development  of  Execution  Framework  Mappings 

4.  Prototyping  an  Initial  Executable  Program 

6.2  Semantic  Analysis 

The  semantic  analysis  portion  of  the  compilation  process  consists  of  various  checks 
that  ensure  a  program  fits  together  in  a  meaningful  way  prior  to  generating  an  executable 
program  (1:5).  For  this  research  effort,  two  semantic  analysis  tasks  were  identified  to  sim¬ 
plify  the  translation  phase:  shorthand  expansion  and  type  checking.  In  general,  shorthand 

^This  chapter  was  co-written  with  Captain  Catherine  Lin.  It  also  appears  in  (23). 
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expansion  augments  the  AST  by  including  the  signatures  and  axioms  of  any  referenced 
components.  Type  checking  ensures  that  operators  used  in  expressions  are  not  applied  to 
incompatible  operands.  Figure  6.1  illustrates  the  sequencing  of  these  two  tasks. 
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SYNTAX  TREE 


TYPE- 

CHECKING 


INTERMEDIATE 
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Figure  6.1  Semantic  Analysis  Phases 


While  the  following  subsections  describe  the  analysis  and  design  performed  for  the 
languages’  shorthand  expansion,  it  was  decided  that  type  checking  would  not  be  addressed 
during  this  research  effort  for  two  reasons: 


1.  The  existence  and  accessibility  of  stand-alone  type-checkers,  i.e.,  MIT’s  Larch  Shared 
Language  (LSL)  Checker  (16)  and  DePaul  University’s  Z  Type  Checker  (ZTC)  (18), 
provided  an  interim  verification  capability. 

2.  Since  type  checking  is  essentially  an  implementation  task,  it  could  be  reserved  for 
future  enhancements. 

6.2.1  Shorthand  Expansion  Analysis.  In  an  abstract  specification,  shorthand 
notations  are  used  to  promote  modularity  and  encapsulation  through  a  reduction  in  the 
amount  of  formal  text.  To  translate  a  specification  into  a  concrete  implementation  requires 
the  expansion  of  these  notations  to  produce  a  robust  intermediate  representation.  In  a 
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Larch  specification,  shorthand  expansion  consists  of  unioning  the  operators  and  axioms 
of  the  “includes”  trait  with  the  original  referencing  trait.  In  a  document,  there  can  be 
many  different  types  of  shorthand  notation,  e.g.,  the  A/S  operations  and  the  numerous 
schema  calculus  expressions,  such  as  schema  inclusion. 

In  terms  of  the  unified  model,  the  schema  inclusion  notation  is  comparable  to  Larch’s 
“includes”  mechanism,  whereby  the  schemas’  signatures  are  merged  and  the  predicates  are 
conjoined  (22:42).  In  contrast,  however,  the  A  and  H  notations  do  not  have  Larch  coun¬ 
terparts.  Described  in  Section  4.3.3,  these  prefixes  can  be  attached  to  a  schema  name  in 
order  to  indicate  types  of  schema  importation.  To  demonstrate  the  underlying  semantics 
of  the  two  conventions,  consider  the  following  schema,  S,  as  a  reference  point. 

S _ 

i,j  :Af 

i  >  j 


Figure  6.2  Example  Schema  S 

The  succinct  notation  of  the  A  and  5  conventions  are  used  to  distinguish  updates 
from  observations.  Specifically,  Z’s  A  convention,  as  in  other  areas  of  mathematics,  is  used 
to  signify  a  change  in  state.  Recalling  that  the  tick  (’)  decoration  indicates  a  post-operation 
value,  the  implicit  definition  of  this  notation  is  given  as:  AState  =  [State]  State^].  The 
syntax  of  the  expanded  A  schema  for  schema  S  is  provided  in  Figure  6.3. 

In  Z,  the  E  symbol,  chosen  because  of  its  similarity  in  appearance  to  the  equivalence 
symbol  (=),  signifies  the  state  of  the  schema  before  and  after  an  operation  where  all  of  the 
schema’s  components  remain  unchanged  (22:45).  The  default  definition  of  the  H  convention 
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is  as  follows:  SState  =  [AState  \  vl’  =  vl  A  v2’  =  v2  A  ...  vk’  =  vk],  where  vl.  .vk  inclusive 
are  the  variables  of  State.  A  visual  representation  of  an  expanded  S  schema  is  depicted  in 
Figure  6.4. 


_A5 _ 

i,j  :  Af 

i  >  j 
i'  >  j' 


Figure  6.3  Expanded  Delta  Schema 


To  address  the  wide  variety  of  shorthand  notations,  two  alternative  expansion  ap¬ 
proaches  were  evaluated.  The  first  alternative  combines  the  parsing  task  with  the  short¬ 
hand  expansion,  while  the  second  alternative  maintains  a  separation  between  syntax  and 
semantics. 


6. 2. 1.1  Addition  of  Explicit  Production  Semantics.  Although  the  compila¬ 
tion  analysis  phase  depicted  in  Figure  4.1  distinguished  between  the  parsing  and  seman¬ 
tic  analysis  phases,  some  language  compilers  do  merge  these  two  tasks.  Supporting  this 
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approach,  DIALECT  possesses  the  capability  to  embed  semantic  analysis  tasks  within  a 
language’s  production  rules.  The  DIALECT  Users  Manual  outlines  two  situations  where 
these  explicit  production  semantics  are  effective  (36:5-17): 

•  Productions  where  the  user  must  set  attributes  of  an  object  that  are  not  fully  de¬ 
scribed  by  the  syntax. 

•  Productions  that  are  used  to  augment  the  syntactic  inheritance  hierarchy. 

The  second  instance  appeared  to  be  applicable  to  this  research  effort;  however,  a 
prototyping  effort  yielded  disappointing  results.  The  production  semantics,  as  defined  in 
the  Dialect  manual,  did  not  appear  to  augment  the  ASTs,  and  it  could  not  be  discerned 
whether  the  added  production  semantics  had  any  effect  on  the  languages’  rules.  Further¬ 
more,  it  seemed  that  the  production  semantics  required  terminal  objects  (i.e.,  the  lowest 
level  objects  in  the  domain  models)  in  its  definition,  which  constrained  the  effective  range 
of  this  approach.  Therefore,  this  alternative  was  deemed  inappropriate. 

6. 2. 1.2  Development  of  Traversal  Algorithms.  The  second  alternative  for 
augmenting  the  ASTs  required  the  creation  of  tree  traversal  algorithms.  Essentially,  this 
methodology  uses  Refine  programs  to  manipulate  the  object  base  created  during  parsing, 
thereby  expanding  the  shorthand  notations.  As  a  prototype,  the  following  generic  traversal 
steps  were  developed: 

1.  Locate  the  shorthand  notation  objects. 

2.  For  each  included  object,  collect  its  signatures  and  axioms. 

3.  Augment  the  object  base  with  the  collected  signatures  and  axioms. 
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After  prototyping  the  predefined  algorithm,  the  resultant  ASTs  were  viewed  for  ac¬ 
curacy  and  completeness.  The  test  specification  had  been  augmented  with  the  collected 
signatures  and  invariants.  Also,  because  this  approach  maintained  disjoint  syntactical  and 
semantic  phases,  the  grammars’  production  rules  were  not  corrupted.  Supported  by  this 
evidence,  this  alternative  was  selected  for  implementing  shorthand  expansions. 

6.2.2  Implementation  of  Traversal  Algorithms.  For  manageability,  the  imple¬ 
mentation  of  the  traversal  algorithms  was  divided  into  two  separate  phases.  Contained  in 
Appendix  J,  the  completed  routines  are  depicted  in  the  structure  chart  in  Figure  6.5. 


Figure  6.5  Traversal  Routines 


In  the  first  implementation  phase,  the  successful  test  algorithm  was  directly  trans¬ 
lated  into  routines  for  the  ULarch  “includes”  notation  and  Used’s  schema  inheritance. 
A  summary  of  the  respective  routines  is  provided; 
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1.  Make-IncLUDES-Link:  An  “Including”  trait’s  theory  is  expanded  by  unioning  the 
Included  trait’s  operators  and  axioms. 

2.  Make- Schema-Inclusion:  A  state  schema’s  signature  is  unioned  with  the  refer¬ 
enced  object  schema’s  signature.  Additionally,  the  predicates  of  both  schemas  are 
conjuncted  together  within  the  state  schema’s  predicate. 

For  the  second  phase  of  the  iteration,  based  on  frequency  of  use  and  correlation 
to  the  Rumbaugh  model,  the  more  complicated  A  and  H  notations  were  implemented. 
Due  to  time  constraints,  the  algorithms  for  the  less  frequently  used  Z  schema  calculus 
expressions  were  reserved  for  future  enhancements.  The  specific  routines  developed  for  the 
two  conventions  are  listed  below: 

1.  Make-Delta- Schemas:  A  A  reference  is  expanded  by  unioning  the  signature  of 
the  A  schema  with  the  signature  of  the  referenced  schema.  Likewise,  the  predicates 
of  both  schemas  are  conjuncted  together.  A  boolean  annotation  attribute,  delta-link, 
is  set  to  true. 

•  Make-Delta- Vars:  If  its  delta-link  attribute  is  true,  the  A  signature  is  ex¬ 
panded  a  second  time  to  include  the  ticked  counterparts  of  the  referenced  ob¬ 
ject’s  variables.  Also,  the  predicate  is  expanded  to  include  the  corresponding 
constraints  placed  on  those  ticked  variables  (See  Figure  6.3). 

2.  Make-Xi-SchemaS:  a  E  reference  is  expanded  by  unioning  the  signature  of  the  E 
schema  with  the  signature  of  the  referenced  schema.  Likewise,  the  predicates  of  both 
schemas  are  conjuncted  together.  A  boolean  annotation  attribute,  xi-link,  is  set  to 
true. 


6-7 


•  Make-Xi-Vars:  If  its  xi-link  attribute  is  true,  the  E  signature  is  expanded  a 
second  time  to  include  the  ticked  counterparts  of  the  referenced  object’s  vari¬ 
ables.  Also,  the  predicate  is  expanded  to  include  the  corresponding  constraints 
placed  on  both  the  ticked  and  unticked  variables  (See  Figure  6.4). 

6.2.3  Validation  of  Algorithms.  The  testing  and  validation  of  the  traversal  al¬ 
gorithms  consisted  of  visually  inspecting  the  augmented  ASTs  with  OBJECT  INSPECTOR. 
During  this  process,  two  types  of  errors  were  detected:  misplacement  within  the  hierarchy 
and  replication  of  variables.  In  the  first  case,  incorrect  attribute  references  caused  the 
“included”  signatures  and  axioms  to  be  appended  to  the  wrong  parent  class.  In  the  second 
case,  the  temporary  set  used  to  collect  the  referenced  signatures  and  axioms  was  not  being 
emptied  between  enumerations.  Upon  correction  of  these  errors,  the  traversal  algorithms 
generated  the  correct  results,  thereby  producing  robust  intermediate  representations  of 
the  source  languages.  The  next  phase  of  development  focused  on  the  target  execution 
framework. 

6.3  Creation  of  an  Execution  Domain  Model 

After  completing  the  compilation  analysis  phase,  the  first  step  in  designing  an  execu¬ 
tion  framework  required  the  creation  of  a  domain  model  for  the  target  execution  language. 
Refine.  Analyzing  the  syntax  of  the  language  produced  four  major  object  classes  as  the 
target  data  structures:  object  classes,  map  attributes,  functions,  and  rules.  The  object 
classes  and  map  attributes  were  identified  as  terminal  objects,  while  the  function  and  rule 
classes  each  decomposed  into  local  parameters  and  a  set  of  preconditions  and  postcon- 
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ditions.  Figure  6.6  illustrates  the  major  object  classes  of  the  execution  domain  model. 
Once  defined,  the  objects  and  associations  in  the  domain  model  mapped  directly  into  the 
object  classes  and  map  attributes  of  a  REFINE  description.  This  description  reflected  the 
execution  domain  model,  thus  establishing  a  concrete  target  for  the  execution  framework 
mappings.  (See  Appendix  K  for  the  complete  graphical  model  and  Appendix  L  for  the 
corresponding  REFINE  implementation.) 


Figure  6.6  Execution  Target  Domain  Model 


6.4  Development  of  Execution  Framework  Mappings 

Developing  a  translation  process  between  the  source  and  target  domain  models  re¬ 
quired  mapping  the  ULarch  and  \JZed  objects  to  the  corresponding  REFINE  objects. 
Three  execution  maps  were  developed  to  correlate  with  the  unified  framework:  an  object 
theory,  a  dynamic  theory,  and  a  functional  theory  map.  A  two  phase  process  was  used  for 
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each  mapping.  First,  an  initial  translation  model  defined  the  appropriate  Refine  object 
classes.  Since  an  object  theory  models  the  structure  of  a  system  and  may  identify  some 
initialization  routines,  the  target  objects  for  this  mapping  were  defined  as  Refine  object 
classes,  map  attributes,  and  functions.  Refine  functions  were  also  defined  for  both  the 
dynamic  and  functional  theories,  since  the  former  captures  a  system’s  static  states  and 
events,  while  the  latter  models  data  transformations. 

The  second  phase  of  each  mapping  process  required  an  analysis  of  both  the  ULarch 
and  models  in  order  to  match  their  individual  structures  to  the  corresponding  Re¬ 

fine  target  components.  While  similar  dynamic  and  functional  theory  mappings  were 
produced,  the  object  theory  mappings  were  significantly  different  because  UZed’s  object 
theory  predicates  are  realized  after  state  initialization,  i.e.,  within  the  subsequent  dynamic 
and  functional  theories.  As  a  result  of  this  difference,  the  lower  right  portion  of  Table  6.1 
remains  empty,  while  Table  6.2  is  complete. 


Table  6.1  ULarch  and  U.Zed  Object  Theory  Maps 


Execution  Target  Object 

ULarch  Source  Object 

VZed  Source  Object 

Object  Class  Name 

Theory  Id 

Object  Theory  Id 

Map  Attributes 

Attribute  Name 

Attribute  Domain 
Attribute  Range 

Tuple  Object 

Tuple  Field  Ids 

Theory  Id 

Tuple  Field  Sort  Id 

Object  Theory  Declarations 
Basic  Identifiers 

Object  Theory  Id 

Any  Expressions 

Functions 

Function  Name 

Function  Parameters 
Function  Parameter  Type 
Function  Return  Type 
Function  Let  Statements 
Function  Preconditions 
Function  Postconditions 

Operators 

Operator  Name 
Quantifier  Variable  Ids 
Quantifier  Sort  Id 
Operator  Range  Id 
Theory  Axioms 

Theory  Axioms 

Theory  Axioms 
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Table  6.2  ULarch  and  XiZed  Dynamic  and  Functional  Theory  Maps 


Execution  Target  Object 

ULarch  Source  Object 

U^ed  Source  Object 

Functions 

Function  Name 

Function  Parameters 
Function  Parameter  Type 
Function  Return  Type 
Function  Let  Statements 
Function  Preconditions 
Function  Postconditions 

Operators 

Operator  Name 
Quantifier  Variable  Ids 
Quantifier  Sort  Id 
Operator  Range  Id 
Theory  Axioms 

Theory  Axioms 

Theory  Axioms 

State/Event/Fun  Theory  Body 
State/Event/Fun  Id 
State/Event/Fun  Declarations 

Any  Expressions 

Identifiers 

Any  State/Event/Fun  Predicates 
State/Fun  Post  Predicates 

6.5  Prototyping  an  Initial  Executable  Program 

The  feasibility  of  generating  code  from  the  execution  maps  was  demonstrated  by 
prototyping  an  executable  shell  for  the  counter  and  fuel  tank  specifications.  The  execu¬ 
tion  shells  contained  the  required  object  classes,  map  attributes,  and  function  names  for 
creating  an  executable  program.  The  shells  were  created  by  a  sequence  of  four  translation 
algorithms,  illustrated  in  Figure  6.7  and  described  below: 


1.  Make  Object  Class:  Translates  application  objects  in  a  formal  specification  into  RE¬ 
FINE  object  classes. 

2.  Make  Attributes:  Finds  the  formal  representation  of  an  object’s  attributes  and  trans¬ 
lates  them  into  map  attributes  with  the  appropriate  domain  and  range  values. 

3.  Make  Functions:  Translates  the  formal  operations  defined  in  ULarch  and  U.^ed  and 
creates  a  corresponding  function  name. 

4.  Print  Program:  Outputs  the  executable  shell.  The  appropriate  object  classes,  map 
attributes,  and  function  names  are  listed  in  the  correct  REFINE  format. 
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Appendix  M  contains  the  initial  translation  algorithms. 


Figure  6.7  Translation  Algorithms 


6.5.1  Deficiencies  in  the  Execution  Maps.  Constrained  by  time,  the  execution 
mappings  were  limited  to  a  subset  of  the  major  object  classes  within  the  REFINE  target 
domain  model  (refer  to  Figure  6.6).  As  a  result,  the  initial  prototyping  effort  did  not 
complete  the  translation  mechanism  for  the  target  model’s  function  and  rule  object  classes. 
These  uncorrected  deficiencies  are  detailed  below. 

1.  Make- Functions:  This  mapping  does  not  currently  translate  formal  parameters  and 
theory  axioms  into  appropriate  function  parameters,  preconditions,  and  postcondi¬ 
tions.  The  translation  must  differentiate  between  theory  axioms  used  as  precondi¬ 
tions  and  those  used  as  postconditions. 

2.  Make-Rules:  The  algorithm  and  mapping  for  this  REFINE  object  class  does  not  exist. 
This  translation  determines  the  sequences  of  events  based  on  the  state  transition 
tables. 
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6. 6  Summary 


Developing  an  execution  framework  proved  extremely  useful  for  demonstrating  the 
feasibility  of  generating  code  from  a  formal  specification.  The  framework  established  the 
target  data  structures  and  functions  for  a  consistent  and  correct  translation  process.  It  also 
became  the  foundation  for  developing  the  execution  maps  from  the  unified  source  models 
into  the  RefINE  target  model.  From  the  execution  maps,  specific  translation  algorithms 
were  created  to  generate  executable  Refine  code  for  the  ULarch  and  U.2€d  counter  and 
fuel  tank  specifications. 
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VII.  Conclusions  and  Recommendations 


This  chapter  provides  a  summary  of  the  accomplishments  of  this  thesis  effort.  Ad¬ 
ditionally,  it  describes  the  conclusions  that  can  be  drawn  from  this  work  and  details  some 
recommendations  for  further  research  in  this  area. 

7.1  Summary  of  Accomplishments 

The  objective  of  this  research  was  to  establish  a  foundation  for  a  next  generation 
application  composition  system  via  the  development  of  a  formalized  object-based  transfor¬ 
mation  process.  The  specific  goal  was  stated  in  Chapter  I: 

Formalize  the  object-based  composition  approach  via  the  transformation  of  Z- 
based  domain  models  into  an  executable  framework,  while  incorporating  a  uni¬ 
fication  with  corresponding  algebraic-based  models. 

Commencing  with  an  extensive  literature  review  of  six  topics  relevant  to  the  design 
of  a  unifying  Z  compiler,  the  resultant  knowledge  base  outlined  the  basic  disciplines  for  the 
product’s  development,  i.e.,  flexibility,  extensibility,  reliability,  and  verifiability.  To  that 
end,  an  evolutionary  development  strategy  was  used  to  partition  the  compiler’s  develop¬ 
ment  into  three  major  iterations: 

1.  Z  parser  development  (including  Mathematical  ToolKit) 

2.  Unified  model  development 

3.  Execution  framework  development 

Implemented  within  predefined  constraints  of  coverage,  consistency,  and  correctness, 
these  major  evolutions  resulted  in  a  robust  and  accurate  framework  for  the  formal  trans- 
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formation  of  object-oriented  domain  models,  thereby  supporting  the  feasibility  of  a  next 
generation  application  composition  system. 

1.2  General  Conclusions^ 

The  following  general  conclusions  can  be  drawn  from  this  research: 

1.  Formal  languages  contain  a  basic  set  of  core  constructs.  Even  though  formal  lan¬ 
guages’  syntactic  domains  differ,  they  are  all  fundamentally  based  on  mathematics. 
This  common  core  identifies  a  canonical  representation  that  can  be  inherited  by  the 
various  language  notations,  or  dialects.  This  canonical  form  is  essentially  a  funda¬ 
mental  statement  to  which  other  statements  can  be  reduced  without  a  loss  of  gener¬ 
ality  (30).  Analysis  of  the  abstract  syntax  trees  (ASTs)  for  Larch  and  Z  identified 
these  fundamental  constructs  and  they,  in  turn,  evolved  into  the  unified  core  domain 
model.  The  notion  of  language  inheritance  fulfills  the  essence  of  reuse  by  creating  a 
consolidated  framework  for  formal  languages  (3). 

Additionally,  this  consolidated  framework  establishes  a  front-end  for  formal  system 
composition.  This  front-end  can  support  three  principal  processes:  design  refine¬ 
ment,  theorem  proving,  and  code  generation,  as  depicted  in  Figure  7.1.  The  unified 
framework  can  produce  synthesis  diagrams  to  support  the  notion  of  theory-based 
design  refinement  (44)  (6).  Theorem  proving  sentences  can  also  be  generated  from 
the  unified  model  for  input  into  a  theorem  prover  to  verify  a  specification.  Finally, 
^This  section  was  co-written  with  Captain  Catherine  Lin.  It  also  appears  in  (23). 
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the  unified  model  forms  the  basis  for  creating  interface  languages  for  the  purpose  of 
specification  execution. 


Z  PARSER  LARCH  PARSER 


Figure  7.1  Expanded  Transformation  Process 


2.  The  evolutionary  development  strategy  is  well-suited  for  developing  a  formal  lan¬ 
guage  compiler  because  the  compilation  process  can  be  decomposed  into  several 
stages.  Each  stage  produces  an  operational  product  demonstrating  a  minimum  set 
of  capabilities,  and  each  incremental  product  is  easily  extensible. 
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3.  Developing  object-oriented  domain  models  for  Larch  and  Z  clarified  the  languages’ 
structures  by  identifying  the  important  objects  and  associations.  The  established 
domain  models  guided  the  development  of  the  grammars,  thereby  constructing  each 
language’s  syntactic  hierarchy. 

4.  The  Refine  environment  simplifies  the  development  of  a  formal  language  parser  and 
an  initial  execution  framework  by  providing  compilation  tools,  i.e.,  DIALECT  and 
Object  Inspector.  Dialect  handles  token  formation  and  creates  an  explicit  hier¬ 
archy  for  Z  using  a  BNF  notation.  These  hierarchies,  in  the  form  of  ASTs,  are  stored 
in  the  object  base  and  viewed  using  Object  INSPECTOR.  A  visual  representation 
is  extremely  beneficial  because  it  allows  one  to  inspect  the  parse  tree  and  under¬ 
stand  the  underlying  structure  of  the  formal  language.  ASTs  also  provide  a  strong 
foundation  to  perform  semantic  analysis  and  begin  building  an  execution  framework. 

7. 3  Specific  Conclusions 

The  following  specific  conclusions  can  be  drawn  about  the  Z  and  UZed  parsers  and 
the  formal  transformation  of  object-based  specifications. 

1.  A  unified  parser  for  the  Z  and  the  Larch  specification  languages  successfully  demon¬ 
strates  the  feasibility  of  using  as  a  theory-based  specification  approach.  The  under¬ 
lying  canonical  form  of  the  composite  framework  promotes  reusability  and  a  single 
focal  point  for  the  execution  model. 

2.  The  grammar  inheritance  mechanism  of  DIALECT  preserved  the  de  facto  relationship 
between  the  core  Z  language  and  the  Mathematical  ToolKit.  This  feature  not  only 
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supports  the  generally  accepted  criteria  of  encapsulation  and  modularity,  but  it  also 
bolsters  the  acceptance  of  this  tool  within  the  Z  community. 

3.  The  Z  and  U Zed  parsers  provide  extensive  coverage  of  the  language’s  syntax  (based  on 
the  First  Edition  of  Spivey’s  notation  (45)).  Their  robustness  was  demonstrated  by 
the  successful  handling  of  a  wide  variety  of  specification  documents.  (See  Appendices 
A  through  C  for  explicit  examples.) 

4.  The  Z  and  UZed  parsers  generate  well-defined  abstract  syntax  trees  that  simplify  the 
semantic  analysis  and  code  generation  phases  of  the  compilation  process.  Specifically, 
for  this  research  elfort,  the  ASTs  simplified  the  semantic  analysis  tasks  of  shorthand 
expansion  and  the  initial  execution  translation  described  in  Chapter  VI.  Additionally, 
the  AST  structures  provide  the  capability  for  constructing  an  interface  to  other 
language-based  tools,  such  as  theorem  provers. 

5.  The  Z  and  U.Zed  parsers  are  extensible.  Z's  domain  model  and  syntax  allow  devel¬ 
opers  to  extend  the  current  language  model  in  a  straightforward  fashion  by  defining 
new  subclasses.  This  flexibility  will  prove  useful  when  the  parsers  are  updated  to  the 
Second  Edition  of  Spivey’s  notation  (46). 

6.  Refine’s  direct  support  of  set  theory  and  set-based  operations  was  expressly  bene¬ 
ficial  to  this  research  effort.  Specifically,  the  “enumerate”  construct  of  the  Refine 
language  was  well-suited  to  the  implementation  of  Z’s  semantic  analysis  tasks,  i.e., 
shorthand  expansion. 
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7.-^  Recommendations  for  Further  Research 


The  following  issues  should  be  addressed  in  future  research  efforts: 

1.  Further  Validate  the  UZed  Parser  -  A  preliminary  collection  of  specification  test  cases 
was  used  to  complete  the  initial  validation  of  the  U^ed  parser.  This  established  test 
set  should  be  augmented  with  additional  examples  in  order  to  further  validate  the 
coverage  and  consistency  of  the  parser. 

2.  Optimize  the  UZed  Grammar  -  The  current  implementation  of  the  Z  parser  requires 
additional  parentheses  within  certain  predicates  and  expressions  to  reduce  ambiguity. 
In  future  versions  of  the  grammar,  these  constraints  should  be  removed  without 
corrupting  the  grammar  or  introducing  spurious  ambiguities. 

3.  Extend  the  Unified  Abstract  Framework  -  The  goal  for  establishing  a  unified  abstract 
framework  is  to  provide  a  common  base  language  with  small  variant  specializations 
or  dialects.  However,  the  framework  produced  during  this  research  does  not  reflect 
a  complete  common  core  because  each  language  has  not  been  reduced  down  to  its 
most  significant  form.  Decreasing  the  size  of  the  language-specific  extensions  re¬ 
quires  pushing  the  specializations  down  to  the  lowest  possible  level  in  the  unified 
model.  Pushing  is  defined  as  the  consolidation  and  resolution  of  similar  constructs 
via  pattern  matching  and  term  rewriting  routines.  The  pattern  matching  tasks  are 
applied  to  the  syntactic  components  of  the  ASTs  and  identify  language  commonali¬ 
ties.  Mathematically  verifiable  procedures  known  as  term  rewriting  are  then  used  to 
translate  the  commonalities  into  a  target  canonical  form. 
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4.  Implement  a  Comprehensive  Suite  of  Semantic  Analysis  Tasks  -  In  addition  to  pat¬ 
tern  matching  and  term  rewriting,  the  following  semantic  analysis  tasks  are  required 
for  complete  Z  compilation; 

•  Expansion  of  Schema  Calculus  Expressions  -  As  discussed  in  Section  6.2.1, 
schema  calculus  is  another  type  of  shorthand  notation  used  to  avoid  mono¬ 
lithic  descriptions.  The  schema  calculus  operators  produce  expressions  which 
combine  existing  schemas  into  new,  more  complex  descriptions  (35:204).  During 
semantic  analysis,  the  resultant  combinations  must  be  dissected,  expanded,  and 
checked  for  type  compatibility. 

•  Precondition  Calculations  -Isx  Z,  &  precondition  is  defined  as  a  predicate  that 
defines  the  domain  of  an  operation  that  represents  a  relation  between  a  start 
and  resulting  state  space  (35:216).  Expansion  of  the  schema  calculus  hiding  (\) 
operator  requires  precondition  calculations  to  uncover  any  operation  schema 
defects,  i.e.,  false  preconditions. 

•  Type  Checking  -  Type  checking  ensures  that  operators  used  in  expressions  are 
not  applied  to  incompatible  operands  (1).  Although  existing  type-checkers 
are  suitable  for  stand-alone  verification,  the  incorporation  of  an  internal  type- 
checker  would  provide  a  continuous  compilation  path  within  the  REFINE  envi¬ 
ronment. 

5.  Identify  Theorem  Proving  Tasks  -  During  the  refinement  of  a  specification  into  exe¬ 
cutable  code,  it  is  vital  that  the  ability  to  reason  formally  be  retained.  Mathematical 
theorems  and  proofs  enable  formal  reasoning  and  should  be  used  to  demonstrate  con- 
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sistency  and  completeness  (32:145).  The  availability  of  automated  theorem  provers 
presents  an  opportunity  for  performing  incremental  verifications  of  the  specification 
throughout  the  refinement  process. 

To  capitalize  on  these  resources,  further  research  should  identify  potential  theorem 
proving  tasks.  Intuitively,  these  tasks  could  be  correlated  to  the  two  major  phases 
of  refinement:  data  and  operation.  In  the  data  refinement  phase,  a  concrete  data 
type  must  be  constructed  to  simulate  each  abstract  one.  The  abstract  state  must  be 
adequately  represented  by  the  concrete  types  and  each  abstract  operation  must  be 
correctly  recast  over  the  new  state  (35:243).  Potential  theorem  proving  tasks  for  this 
phase  include: 

(a)  Verify  that  each  abstract  variable  can  be  retrieved  from  the  concrete  ones. 

(b)  Verify  that  the  concrete  initial  state  describes  an  abstract  counterpart. 

(c)  Verify  that  each  concrete  operation  has  a  function  that  at  least  encompasses  its 
abstract  partner. 

(d)  Verify  that  each  concrete  operation  produces  behavior  that  its  abstract  partner 
would  be  capable  of  producing. 

In  the  operation  refinement  phase,  each  concrete  operation  is  transformed  into  an 
implementation  algorithm  using  rules  and  checks  to  guarantee  correctness.  Possible 
theorem  proving  tasks  at  this  stage  include: 

(a)  Verify  that  the  strength  of  the  predicates  is  not  diminished. 

(b)  Verify  that  variable  bindings  are  maintained. 
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6.  Complete  the  Execution  Framework  -  To  complete  the  execution  framework  the  fol¬ 
lowing  tasks  are  required: 

•  Additional  Mapping  Analysis  -  Required  to  complete  the  translation  of  ax¬ 
iomatic  equations  in  Larch  and  schema  predicates  in  Z  into  REFINE  functions. 
The  main  emphasis  for  this  task  centers  around  identifying  the  appropriate  pre¬ 
conditions  and  postconditions  to  establish  the  corresponding  REFINE  transform 
operations. 

•  Execution  Translation  -  Complete  translation  of  the  function  and  rule  classes 
is  the  final  task  in  completing  the  execution  framework.  This  task  produces  an 
executable  program  of  a  formally  specified  problem. 

•  System  Testing  -  Necessary  to  validate  the  entire  formal  compilation  process. 
The  established  validation  domains,  counter  and  fuel  tank,  should  be  used  to 
demonstrate  and  validate  the  execution  of  the  specified  behavior.  Additionally, 
in  order  to  satisfy  the  constraints  of  completeness  and  consistency,  larger  and 
more  robust  domains  should  be  evaluated. 

•  System  Verification  -  Required  to  verify  the  consistency  of  the  execution  trans¬ 
lation,  i.e.,  Z  Behavior  =>  Refine  Behavior.  For  example,  theorem  proving 
tasks  need  to  be  identified  to  verify  that  set-formers  in  the  Z  specification  are 
consistent  with  set-formers  in  the  Refine  program. 

For  a  “big  picture”  perspective  of  these  recommendations  with  respect  to  the  formal¬ 
ized  transformation  process.  Figure  7.2  depicts  a  visualization  of  the  complete  target 
process  model. 
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7. 5  Final  Comments 


The  desirable  characteristics  of  future  software  development  will  be  an  amalgamation 
of  various  disciplines  and  methodologies  (24:53).  Foremost  of  these  attributes  is  the  com¬ 
bination  of  formal  languages  with  object-oriented  analyses.  The  formalized  object  trans¬ 
formation  process  developed  during  this  thesis  effort  possesses  this  attribute  and  therefore, 
is  a  significant  milestone  toward  the  establishment  of  the  next  generation  application  com¬ 
position  system.  Additionally,  this  research  provides  an  initial  capability  for  the  correct 
and  consistent  execution  of  Z,  thereby  strengthening  and  extending  the  software  engineer’s 
toolkit. 


7-11 


Appendix  A.  Counter  Specification  OMT  Analysis  Models 

The  Counter  Analysis  Models  were  selected  as  an  informal  testing  domain  for  the 
formal  object  transformation  process.  This  appendix  contains  the  OMT  analysis  models 
and  the  resultant  Z  specification. 

OBJECT  MODEL 


Figure  A.l  Counter  Object  and  Functional  Models 
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Xdocumentstyle [fullpage ,zed] {article} 

\begiii{  document} 

\begin{schema}{  Counter  }’/,ObjectTheory 
Value  :  \nat\\ 

Limit  :  \nat 
\where 

Value  \leq  Limit 
\end{schema}\\ 

\begin{schema}{  InitCounter  }y.StateTheory 
Coiuiter 
\where 

Value  =  0\\ 

Limit  =  100 
\end{schema}\\ 

\begin{schema}{  Increment  }*/.FunctionalTheory 
\Delta  CounterW 
\where 

Value  <  Limit 
\also 

Value'  =  Value  +  1 
\end{schema}\\ 

\begin{schema}{  Add  }*/,FunctionalTheory 
\Delta  CounterW 
AddValue?  :  \nat\\ 

NewValue !  ;  \nat 

\where 

Value  +  AddValue?  \leq  Limit 
\also 

Value'  =  Value  +  AddValue?\\ 

NewValue !  =  Value ' 

\end{scliema}\\ 

\begin{schema}{  Subtract  }*/,FunctionalTheory 
\Delta  CounterW 
DecValue?  :  \natW 
NewValue !  :  \nat 

\where 

Value  -  DecValue?  \geq  0 
\also 

Value'  =  Value  -  DecValue?W 
NewValue !  =  Value ' 

\end{schema} 

\end{ document}) 
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Appendix  B.  Validation  Specifications 

This  appendix  contains  the  U^ed  parser  validation  specifications.  These  specifica¬ 
tions  contain  examples  of  proper  grammatical  syntax  required  by  the  parser.  One  specific 
item  of  importance  is  the  placement  of  parentheses  around  the  predicates  and  expressions 
listed  below.  These  parentheses  are  necessary  to  reduce  ambiguity  during  parsing. 

1.  Predicates  -  A,  V,  and  =^. 

2.  Schema  Calculus  Expressions  -  A,  V,  4^,  =^,  \,  and  |. 

3.  In-Generic  Expressions  -  -h,  c,  C,  — G->,  -to,  and  C. 

B.l  Data  Dictionary 


\dociimentstyle [fullpage ,zed] {article} 

\begin{ document} 

*/,{\Large\bf  Z  Specification  of  a  Data  Dictionary} 

\begin{zed} 

[  NAME,  INFO  ] 

\end{zed}\\ 

\begin{syntax} 


Response  & 

:  :=  & 

Success  \\ 

& 

1  & 

Found  \\ 

& 

1  & 

Overflow  \\ 

& 

1  & 

Redefined  \\ 

& 

1  & 

Undefined  \\ 

& 

\end{syntax}\\ 

1  & 

NotFound 

\begin{axdef} 

MaxSize  ; 

\nat 

\where 

MaxSize  \leq  65535 
\end{axdef}\\ 


B-1 


\begin{schema}{  DataDictionary  >*/,ObjectTh.eory 
Diet:  NAME  \pfun  INFO  \\ 

Defined:  \power  NAME 
\where 

Defined  =  \dom  Diet  \\ 

\#  Defined  \leq  MaxSize 
\end{schema}\\ 

DataDietInit  \defs  [  DataDietionary’  |  Defined’  =  \empty  ]\\ 

\begin{sehema}{  InsertOK  }‘/,FunetionalTheory 
\Delta  DataDietionaryW 
Name?  :  NAME  \\ 

Info?  :  INFO  \\ 

Resp!  :  Response 
\where 

Name?  \notin  Defined  \\ 

\#  Defined  <  MaxSize  \\ 

Diet’  =  Diet  \eup  X-C  Name?  \mapsto  Info?  \}  \\ 

Resp!  =  Sueeess 
\end{sohema}\\ 

\begin{sehema>{  RemoveOK  }‘/,FunetionalTheory 
\Delta  DataDietionary  \\ 

Name?  :  NAME  \\ 

Resp!  :  Response 
\where 

Name?  \in  Defined  \\ 

Diet’  =  \{  name?  \}  \ndres  Diet  \\ 

Resp!  =  Sueeess 
\ end{ s  ehema} \ \ 

\begin{sehema}{  SearehOK  }y,Funetional'nieory 
\Xi  DataDietionary  \\ 
name?  :  NAME  \\ 
info!  :  INFO  \\ 
resp!  :  Response 
\where 

name?  \in  defined  \\ 
info!  =  diet'name?  \\ 
resp!  =  Found 
\end{sehema}\\ 
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\begin{schema}{  InsertOverf low  }y,FTinctionalTheory 
\Xi  DataDictionary  \\ 

Name?  :  NAME  \\ 

Info?  :  INFO  \\ 

Resp!  :  Response 
\where 

\#  Defined  =  MaxSize  \\ 

Resp!  =  Overflow 
\end{schema}\\ 

\begin-Cschema}-[  InsertAlreadyDef ined  }7«FunctionalTheory 
\Delta  DataDictionary  \\ 

Name?  :  NAME  \\ 

Info?  :  INFO  \\ 

Resp!  :  Response 
\where 

Name?  \in  Defined  \\ 

Diet’  =  Diet  \oplus  \{  Name?  \mapsto  Info?  \}  \\ 

Resp!  =  Redefined 
\ end{ s  chema} \ \ 

\begin{schema>-C  Remo veUndef ined  }y.FunctionalTheory 
\Xi  DataDictionary  \\ 

Name?  :  NAME  \\ 

Resp!  :  Response 
\where 

Name?  \notin  Defined  \\ 

Resp!  =  Undefined 
\end{schema}\\ 

\begin-Cschema}{  SearchUndef ined  J'/.FvinctionalTheory 
\Xi  DataDictionary  \\ 

Name?  ;  NAME  \\ 

Info!  ;  INFO  \\ 

Resp!  :  Response 
\where 

Name?  \notin  Defined  \\ 

Resp!  =  NotFound 
\end{schema>\\ 

Insert  \defs  ((InsertOk  \lor  InsertOverflow)  \lor  InsertAlreadyDef ined) \\ 
Remove  \defs  (RemoveOk  \lor  RemoveUndef ined)\\ 

Search  \defs  (SearchOk  \lor  SearchUndef ined) 

\end{document}) 
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B.2  Specification  of  an  Aircraft  Passenger  Listing 

The  aircraft  passenger  listing  records  the  passengers  aboard  an  aircraft.  There  are  no  seat 
numbers,  passengers  are  allowed  aboard  on  a  first-come-first-served  basis,  and  the  aircraft  has  a 
fixed  capacity.  The  state  of  the  system  is  given  by  the  set  of  people  on  board  the  aircraft,  and 
the  number  of  persons  on  board  must  never  exceed  the  capacity.  There  must  be  operations  to 
allow  a  person  to  both  board  and  disembark  the  aircraft.  Additionally,  there  must  be  operations 
to  discover  the  number  of  persons  on  board  and  whether  or  not  a  given  person  is  in  on  board  (22). 


(#> 

\documentstyle [fullpage ,zed] {article} 

\begin{document} 

y,{\Large\bf  Z  Specification  of  an  Aircraft  Passenger  Listing} 

\begin{zed} 

[  PERSON  ] 

\end{zed}\\ 

\begin{axdef} 

Capacity  :  \nat 
\end{axdef}\\ 

\begin{schema}{  AirCraft  }y,ObjectTheory 
OnBoard  :  \power  PERSON 
\where 

\#  OnBoard  \leq  Capacity 
\end{schema}\\ 

\begin{schema}{  InitAirCraft  }y.StateTheory 
Aircraft 
\where 

OnBoard  =  \{\empty\} 

\end{schema}\\ 

\begin{scheina}{  InitBoard  }y,FunctionalTheory 
\Delta  AirCraftW 
Person?  :  PERSON 
\where 

Person?  \notin  OnBoardW 

\#  OnBoard  <  CapacityW 

Onboard’  =  OnBoard  \cup  \{  Person?  \} 

\end{schema}\\ 
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\begiii{schema}{  InitDisembark  }y,FunctionalTheory 
\Delta  AirCraftW 
Person?  :  PERSON 
\where 

Person?  \in  OnBoardW 

Onboard’  =  OnBoard  \setminus  \{  Person?  \} 

\end{schema}\\ 

\begin{scheina}{  NvunberOnBoard  }7,FunctionalTheory 
\Xi  AirCraftW 
MnmOnBoard !  :  \nat 

\where 

NumOnBoard!  \in  \#  OnBoard 
\end{schema}\\ 

\begin{syntax} 

AMSWERTYPE  : :=  Yes  |  No 
\ end{ synt  ax} \ \ 

\begin{schema}-[  PersonOnBoard  }*/,FunctionalTheory 
\Xi  AirCraftW 
Person?  :  PERSONW 
Reply!  :  ANSWERTYPE 
\where 

((Person?  \in  OnBoard  \land  Reply!  =  Yes)  \lor 
(Person?  \notin  OnBoard  \land  Reply!  =  No)) 

\end{schema>W 

\begin{syntax} 

RESPONSETYPE  : OK  I  AlreadyOnBoard  |  Full  I  NotOnBoard  |  TwoErrors 
\end-Csyntax}W 
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\begin-Cschema}{  BoardingError  }y,FunctionalTheory 
\Xi  AirCraftW 
Person?  :  PERSONW 

Response!  :  RESPONSETYPE 

\where 

((((Person?  \in  OnBoard  \land  \#  OnBoard  =  Capacity)  \land 
Response!  =  TwoErrors) 

\lor 

((Person?  \in  OnBoard  \land  \#  OnBoard  <  Capacity)  \land 
Response!  =  AlreadyOnBoard)) 

\lor 

((Person?  \notin  OnBoard  \land  \#  OnBoard  =  Capacity)  \land 
Response!  =  Full)) 

\end{schema}\\ 

Board  \defs  ((InitBoard  \land  OKMESSAGE)  \lor  BoardingError) \\ 

\begin{scheina}{  DisembarkError  }-‘/,FunctionalTheory 
\Xi  AirCraftW 
Person?  :  PERSONW 

Response!  :  RESPONSETYPE 

\where 

(Person?  \notin  OnBoard  \land  Response!  =  NotOnBoard) 
\end{scheraa}W 

Disembark  \defs  ( (InitDisembark  \land  OKMESSAGE)  \lor  DisembarkError) 
\end{document}) 
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B.3  Car  Radio  Specification 

A  digital  car  radio  has  three  wavebands:  medium,  long,  and  UHF.  In  each  band,  there  is  a 
set  of  stations  (usable  wavelengths)  and  the  radio  is  designed  so  that  it  can  be  tuned  only  to  these. 
(That  is,  it  is  impossible  to  select  an  arbitrary  wavelength;  the  operator  can  select  only  transmitting 
stations.)  Initially,  when  the  radio  is  delivered,  the  lowest  station  on  the  medium  band  is  selected. 
The  controls  and  indicators  are  described  as  follows: 

1.  An  MLU  button  -  cycles  round  the  medium,  long,  and  UHF  bands. 

2.  UP/DOWN  buttons  -  change  the  current  station. 

3.  VOL  control  -  adjusts  the  volume  and  acts  as  an  ON/OFF  switch. 

The  MLU  button  will  change  to  the  next  band  (M-L-U-M)  and  select  the  lowest  station  on 
that  band.  The  UP/DOWN  buttons  cause  the  radio  to  search  for  the  next  station  in  the  current 
band  (U,  L  or  M)  either  “up”  or  “down”  the  band.  When  either  end  is  reached,  the  search  “wraps” 
to  the  other  end  of  the  band.  The  MLU  and  UP/DOWN  buttons  have  no  effect  when  the  radio  is 
turned  off  (27:146). 


Xdocument style [fullpage .zed] {article} 
\begin{document} 

y,{\Large\bf  Z  Specification  of  a  Car  Radio} 

\begin{syntax} 

OnOff  ::=  ON  |  OFF 
\end{syntax}\\ 

\begin{axdef} 

MaxVol  :  \nat_l 
\end{axdef}\\ 

\begin{schema}{  Volume  }'/,ObjectTheory 
Volume  :  0  \upto  MaxVolW 
Main  :  OnOff 

\where 

(Main  =  OFF  \iff  Volume  =  0)\\ 

(Main  =  ON  \iff  Volume  >  0) 
\end{schema}\\ 

Wavelength  ==  \nat_l\\ 
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\begin{axdef} 

Waveband  :  \power  (seq  Wavelength) 

\where 

\forall  w  :  WaveBand  \spot  (\forall  i,  j  :  dom  w  |  i  <  j  \spot  wi  <  wj) 
\end{axdef3-\\ 

\begin{axdef } 

Medium,  Long,  UHF  :  WaveBand 
\where 

WaveBand  =  (Medium,  Long,  UHF)\\ 

Medium  \neq  Long  \neq  UHF 
\end{axdef}\\ 

\begin-[schema}{  Bands  }‘/,ObjectTheory 
Band  :  WaveBandW 

Station  :  WaveLengthW 
StationMum  :  \nat_l 
\where 

Station  =  Band  StationNumW 
StationMum  \leq  \#Band 
\end-Cschema}\\ 

\begin{schema3-{  Radio  }’/,ObjectTheory 
RadioVolume  :  VolumeW 
RadioBands  :  Bands 
\end{schema}\\ 

\begin{schema}{  InitRadio  }y,StateTheory 
Radio 
\where 

Main  =  0FF\\ 

StationMum  =  1\\ 

Station  =  Medi\im  1\\ 

Band  =  Medium 
\end{schema}\\ 

MoOp  \defs  Radio  I  Main  =  0FF\\ 

ChangeVol  \defs  Radio  |  (Band’  =  Band  \land  Station’  =  Station)\\ 

\begin{schema}{  IncreaseVol  }7,StateTheory 
ChangeVol 
\where 

((Volume  <  MaxVol  \land  Volume’  =  Volume  +  1) 

\lor 

(Volume  =  0  \land  Volume’  =  Volume)) 

\end{schema}\\ 
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\begin{schema}-[  DecreaseVol  }7,StateTheory 
ChangeVol 
\where 

((Volume  >  0  Maud  Volume’  =  Volume  -  1) 

\lor 

(Volume  =  0  \laiid  Volume’  =  Volume)) 

\end{schema}\\ 

\begin{schema}-(  ChangeStation  >*/,FuiictionalTheory 
\Delta  Radio 
\where 

Main  =  0N\\ 

Volume’  =  VolumeW 
Main’  =  Main\\ 

Band’  =  Band 
\end{schema}\\ 

\begin{schema}-C  UpStation  }7.StateTlieory 
ChangeStation 
\where 

(StationNum  <  \#  Band  \implies  StationNum’  =  StationNum  +  1)\\ 
(StationNum  =  \#  Band  \implies  StationNum’  =  1) 

\end{schema}\\ 

UP  \defs  (UpStation  \lor  NoOp)\\ 

\begin{schema}{  DownStation  }7,StateTheory 
ChcUigeStation 
\where 

(StationNum  >  1  \implies  StationNum’  =  StationNum  -  1)\\ 
(StationNum  =  1  \implies  StationNum’  =  \#  Band) 

Volume’  =  VolumeW 
\end{schema}\\ 

DOWN  \defs  (DownStation  \lor  NoOp)\\ 

\begin{schema}{  Cycle  }7.FunctionalTheory 
\Delta  Radio 
\where 

Main  =  0N\\ 

Volume’  =  VolumeW 
Main’  =  MainW 
StationNum’  =  IW 

(Band  =  Medium  \implies  Band’  =  Long)W 
(Band  =  Long  \implies  Band’  =  UHF)W 
(Band  =  UHF  \implies  Band’  =  Medium) 

\end{schema}W 
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MLU  \defs  (Cycle  \lor  NoOP) 
\  end{do  cment } ) 
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Appendix  C.  Fuel  Tank  Specification  OMT  Analysis  Models 

The  Fuel  Tank  Analysis  Models  were  selected  as  a  validation  domain  for  the  formal 
object  transformation  process.  This  appendix  contains  the  OMT  analysis  models  and  state 
transition  table  developed  by  Hartrum  (17),  and  the  resultant  Z  specification. 


Fuel  Tank 

tankSimTime:  Time 
inputFlowRate:  FlowRate 
outputFlowRate;  FlowRate 

fuel  Level:  Real 
capacity:  Real 

tankWeight:  Real 
fuelDensity:  Real 


Figure  C.l  Fuel  Tank  Object  Model 
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StartFill(flow_rate)/Schedule(TankFull)  StopFill[fuel_level=capacity]/Cancel(T  ankFull);  updatejevel 


Figure  C.2  Fuel  Tank  Dynamic  Model 
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Table  C.l  Fuel  Tank  State  Transition  Table. 


Current 

Event 

Guard 

Next 

Action 

Empty 

StartFill 

Filling 

Schedule(TankFull) 

Filling 

StopFill 

fuelJtevel  =  capacity 

Full 

Cancel(TankFull);  updateJievel 

Filling 

StopFill 

fuel-level  <  capacity 

PartiallyFilled 

Cancel(TankFull);  update-level 

Filling 

TankFull 

Full 

Overflow;  updateJevel 

Filling 

StartUse 

FillAndUse 

Cancel  (TankFull);  update_level 

Full 

StartFill 

Full 

Overflow 

Full 

StartUse 

Using 

Schedule  (TankEmpty) 

Using 

TankEmpty 

Empty 

ChangeFuelFlow(O) ; 
updateJevel 

Using 

StopUse 

PartiallyFilled 

Cancel(TankEmpty) ; 
update-level 

Using 

StartFill 

FillAndUse 

Cancel  (TankEmpty) ; 
updateJevel 

PartiallyFilled 

StartFill 

Filling 

Schedule  (TankFull) 

PartiallyFilled 

StartUse 

Using 

Schedule  (TankEmpty) 

FillAndUse 

StopUse 

Filling 

Schedule  (TankFull) ; 
update-level 

FillAndUse 

StopFill 

Using 

Schedule  (TankEmpty) ; 
update-level 
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Sim  Clock 


Figure  C.4  Fuel  Tank  Functional  Model  -  2 
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\document style [fullpage , zed] {article} 
\begin{ document} 

\begin{zed} 

[  SIMTIME  ] 

\end{zed}\\ 


\begin{schema}{  SimClock  }‘/,ObjectTheory 
SimTime  :  SIMTIME 

\end{schema}\\ 


\begin{schema}{  FuelTank  }"/,QbjectTlieory 


Tanks imTime 

InputFlowRate 

OutputFlowRate 

FuelLevel 

Capacity 

TcinkWeight 

FuelDensity 


SIMTIMEW 
\cal  R\\ 
\cal  R\\ 
\cal  R\\ 
\cal  R\\ 
\cal  R\\ 
\cal  R\\ 


Fue IT ankW e i ght 


\cal  R 


\where 


FuelLevel  \leq  CapacityW 

FuelTankWeight  =  TankWeight  +  FuelDensity  *  FuelLevel 
\end{schema}\\ 


\begin{schema}{  Empty  }y,StateTheory 
FuelTank 
\where 

FuelLevel  =  0\\ 

InputFlowRate  =  0\\ 

OutputFlowRate  =  0 
\end{schema}\\ 

\begin{schema}{  PartiallyFilled  }7,StateTheory 
FuelTank 
\where 

FuelLevel  >  0\\ 

FuelLevel  <  CapacityW 
InputFlowRate  =  0\\ 

OutputFlowRate  =  0 
\end{schema}\\ 


C-6 


\begin-Cschema}{  Full  }‘/,StateTheory 
FuelTank 
\where 

FuelLevel  =  CapacityW 
InputFlowRate  =  0\\ 

OutputFlowRate  =  0 
\end{schema}\\ 

\begin{schema}{  Filling  }‘/,StateTheory 
FuelTank 
\where 

FuelLevel  \geq  0\\ 

FuelLevel  \leq  CapacityW 
InputFlowRate  >  0\\ 

OutputFlowRate  =  0 
\end{ s chema} \ \ 

\begin{schema>-C  Using  }ZStateTheory 
FuelTank 
\where 

FuelLevel  \geq  0\\ 

FuelLevel  \leq  CapacityW 
InputFlowRate  =  OW 
OutputFlowRate  >  0 
\end{schema3-W 

\begin{scheina}{  FillAndUse  >7,StateTheory 
FuelTank 
\where 

FuelLevel  \geq  OW 
FuelLevel  \leq  CapacityW 
InputFlowRate  >  OW 
OutputFlowRate  >  0 
\ end{ s  chema} \ \ 

\begin{schema}-C  Determineinterval  }'/,FunctionalTheory 
\Xi  FuelTankW 
\Xi  SimClockW 
Interval!  :  SIMTIME 
\where 

Interval!  =  SimTime  -  TankSimTime 
\end{schema}W 
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\begin{schema}{  CalculateFilledLevel  }7,FmictionalTheory 
\Delta  FuelTankW 
\Xi  SimClockW 
Interval?  :  SIMTIME 
\where 

FuelLevel’  =  FuelLevel  +  Interval?  *  InputFlowRateW 
TankSimTime ’  =  SimTime 
\end{schema}\\ 

\begin-[schema]-{  PredictTankFullTime  }7.FnnctionalTheory 
\Xi  FuelTankW 

Overf lowEventTime !  :  SIMTIME 

\where 

Overf lowEventTime !  =  TankSimTime  +  Capacity  -  FuelLevel  div  InputFlowRate 
\end{schema}-\\ 

\begin{schema}{  CalculateNetFlow  jy.FunctionalTheory 
\Xi  FuelTankW 
MetFlowRate!  :  \cal  R 
\where 

NetFlowRate!  =  InputFlowRate  -  OutputFlowRate 
\end-Cschema}W 

\begin{sch.ema>{  CalculateFillUseLevel  }y,FianctionalTheory 
\Delta  FuelTankW 
\Xi  SimClockW 
NetFlowRate?  :  \cal  RW 
Interval?  :  SIMTIME 
\where 

FuelLevel’  =  FuelLevel  +  Interval?  *  NetFlowRate?W 
TankSimTime’  =  SimTime 
\end{schema}W 

\begin{schema}{  CalculateUsedLevel  J’/.FunctionalTheory 
\Delta  FuelTeinkW 
\Xi  SimClockW 
interval?  :  SIMTIME 
\where 

FuelLevel’  =  FuelLevel  -  Interval?  *  OutputFlowRate W 
TankSimTime ’  =  SimTime 
\end{schema>W 

\begin{schema}{  PredictTankEmptyTime  }y,FunctionalTheory 
\Xi  FuelTankW 

TankEmptyEventTime !  :  SIMTIME 

\where 

TankEmptyEventTime !  =  TankSimTime  +  FuelLevel  div  OutputFlowRate 
\end{schema}W 
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\begin{schema>{  DetermineFuelWeight  }y,FiiiictionalTheory 
\Xi  FuelTankW 
FuelWeight!  :  \cal  R 
\where 

FuelWeight!  =  FuelLevel  *  FuelDensity 
\end{schema}\\ 

\begin{schema}{  CalculateTotalWeight  jy.FunctionalTheory 
\Xi  FuelTankW 
FuelWeight?  :  \cal  R\\ 

FuelTankWeight I  :  \cal  R 
\where 

FuelTankWeight!  =  FuelWeight?  +  TankWeight 
\ end{ schema} 

\end{document}) 
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Appendix  D.  Unified  Domain  Model 


This  appendix  contains  the  object-oriented  domain  models  for  the  unified  abstract 
framework.  These  models  identify  the  common  object  classes  shared  by  Larch  and  Z.  The 
common  object  classes  promote  a  uniform  interface  for  formalizing  object-oriented  anal¬ 
ysis  models  and  are  the  foundation  for  establishing  a  canonical  representation  for  formal 
specification  languages.  Each  language’s  “dialect”  (i.e.,  the  variances  of  the  language  from 
the  common  core)  is  depicted  in  the  figures  as  specialized  object  classes. 


Figure  D.l  Unified  Domain  Theory  Model 


Figure  D.4  Unified  Functional  Theory  Body 
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Figure  D.5  State  Transisition  Table 
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Appendix  E.  Refine  Code  for  the  Unified  Domain  Model 


This  appendix  contains  the  Refine  code  for  the  unified  abstract  framework  depicted 
in  Appendix  D.  This  code  demonstrates  the  object-based  nature  of  the  Refine  specifi¬ 
cation  language.  The  objects  and  attributes  specified  in  Refine  are  modular  and  easily 
extensible  using  the  notion  of  subclasses  and  tree-attributes.  The  flexibility  of  this  specifi¬ 
cation  language  makes  future  enhancements  to  the  unified  abstract  model  straightforward. 


! !  in-package ("RU") 

!!  in-grammar ( ’user) 

#1  I 

File  name:  unif ied-dm.re 

Description:  The  following  specification  defines  the  Unified  Domain  Model’s 
objects,  attributes,  cind  abstract  syntax  tree.  The  unified  domain  model  was 
constructed  by  analyzing  the  separate  abstract  syntax  trees  (AST)  of  the  Larch 
and  Z  languages. 

II# 


I - 

’/,  Unified  Domain  Model  Object  Class  Definitions 

I - 


var  Unified-Object 
vax  DomainTheory 


:  object-class  subtype-of  user-object 
:  object-class  subtype-of  Unified-Object 


vax  DomainTheoryTypes 
var  ObjectTheory 
var  DyneunicTheory 
var  FunctionalTheory 


:  object-class  subtype-of 
:  object-class  subtype-of 
:  object-class  subtype-of 
:  object-class  subtype-of 


Unified-Object 
DomainThe  oryTyp  e  s 
DomainThe  oryType  s 
DomainTheoryTypes 


var  Theoryld 

var  ObjectTheoryld 
var  DynamicTheoryld 
var  FunctionalTheoryld 


:  object-class  subtype-of 
:  object-class  subtype-of 
:  object-class  subtype-of 
:  object-class  subtype-of 


Unified-Object 

Theoryld 

Theoryld 

Theoryld 


var  TheoryBody 

var  ObjectTheoryBody 
var  DynamicTheoryBody 
var  FunctionalTheoryBody 


object-class  subtype-of 
object-class  subtype-of 
object-class  subtype-of 
object-class  subtype-of 


Unified-Object 

TheoryBody 

TheoryBody 

TheoryBody 


var  TheoryDecl 

var  ObjectTheoryDecl 
var  DynamicTheoryDecl 
var  FunctionalTheoryDecl 


object-class  subtype-of 
object-class  subtype-of 
object-class  subtype-of 
object-class  subtype-of 


Unified-Object 

TheoryDecl 

TheoryDecl 

TheoryDecl 
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var  SignatureDecl 
var  ContextRef 


:  object-class  subtype-of  Unified-Object 
:  object-class  subtype-of  Unified-Object 


var  TheoryAxioms  :  object-class  subtype-of  Unified-Object 

var  ObjectTheoryAxioms  :  object-class  subtype-of  TheoryAxioms 

var  DynamicTheoryAxioms  :  object-class  subtype-of  TheoryAxioms 

var  FunctionalTheoryAxioms :  object-class  subtype-of  TheoryAxioms 


I - 

'/,  Unified  Model  Attribute  Declarations  for  Branches  in  Tree  Structure 

I - 

var  theory-types  :  map(DomainTheory ,  set(DomainTheoryTypes) ) 

computed-using  theory-types (x)  =  {} 


var  theory-id 
var  ot-id 
var  dt-id 
var  ft-id 


:  map(DomainTheoryTypes ,  IdName)  =  {||} 
;  map(DomainTheoryTypes ,  IdName)  =  {||} 
;  mapCDomainTheoryTypes ,  IdNeone)  =  {||} 
:  mapCDomainTheoryTypes,  IdName)  =  {1|> 


var  theory-body 
var  ot-body 
var  dt-body 
var  ft-body 


:  mapCDomainTheoryTypes,  TheoryBody)  =  {||3- 
;  mapCDomainTheoryTypes,  TheoryBody)  =  {M} 
:  mapCDomainTheoryTypes,  TheoryBody)  =  {||3- 
:  mapCDomainTheoryTypes,  TheoryBody)  =  {||)- 


var  theory-decl  :  mapCTheoryBody,  TheoryDecl)  =  {||> 

var  context-refs  :  mapCTheoryDecl,  setCContextRef)) 

computed-using  context-ref sCx)  =  {} 


var  signature-decl 


:  mapCTheoryDecl,  setCSignatureDecl)) 
computed-using  signature-decl Cx)  =  {> 


var  theory-axioms 


:  mapCTheoryBody,  setCTheoryAxioms)) 
computed-using  theory-axioms Cx)  =  {} 


I - 

y,  structure  for  Abstract  Syntax  Tree 

% - 

form  Def ine-Tree-Attributes-of-Unif ied-Specif ication 
Def ine-Tree-AttributesC ’DomainTheory ,  theory-types}) & 

Define-Tree-AttributesC'ObjectTheory,  {’ot-id,  ’ot-body})& 
Define-Tree-AttributesC’DynamicTheory,  {’dt-id,  ’dt-body})& 
Define-Tree-AttributesC’FunctionalTheory,  {’ft-id,  ’ft-body})& 

Def ine-Tree-AttributesC ’TheoryBody ,  {’theory-decl ,  ’theory-axioms})& 

Def ine-Tree-Attributes  C ’ TheoryDecl ,  { ’ signature-decl ,  ’ context-refs}) 
yX  Define-Tree-AttributesC ’TheoryAxioms,  {’/,’/,  fill  in  Larch/Z  specific})* 
y.y,  Def ine-Tree-AttributesC ’ContextRef ,  {’/,'/,  fill  in  Larch/Z  specific})* 
y,y,  Define-Tree-AttributesC ’SignatureDecl,  {7.7,  fill  in  Larch/Z  specific})* 
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Appendix  F.  REFINE  Code  for  the  State  Transition  Table 

This  appendix  contains  the  REFINE  code  for  the  State  Transition  Table  (STT)  illus¬ 
trated  in  Appendix  D.  A  formal  domain  model  and  grammar  do  not  exist  for  the  STT 
because  of  the  limitations  in  both  Z  and  Larch  to  formally  specify  the  entries  in  the  table. 
Thus,  to  complete  a  formal  implementation  of  the  transformation  process,  a  grammar  and 
domain  model  were  developed  to  parse  the  STT,  thereby  generating  initial  objects  to  be 
used  in  the  execution  framework. 


!!  in-package ("RU") 

!!  in-grammar ('user) 

#1  I 

File  name:  stt.re 

Description:  The  following  prograim  defines  the  State  Transition  Table  (STT) 
Domain  Model  eind  the  Grammar.  The  STT  is  part  of  the  OMT  analysis  models 
and  is  required  to  create  a  complete  and  accurate  execution  model  for  the 
formal  transformation  process.  Compilation  of  the  domain  model  and  grammar 
generates  an  STT  parser  for  state  transition  tables  created  using  the  Rumbaugh 
method.  Latex  specific  notations  are  used. 

I  I# 


I - 

7,  STT  Class  Definitions 

5^ - 

var  Table 
var  StateTable 
var  StateEntry 
var  Identifier 


object-class  subtype-of  user-object 
object-class  subtype-of  Table 
object-class  subtype-of  Table 
object-class  subtjrpe-of  Table 


7. 


%  STT  Attribute  Declarations 

9/ 

h 

var  table-name 

map (Table , 

var  table-label 

map (Table , 

var  state-entries 

map (Table , 

var  current-state 

map (Table , 

var  state-event 

map (Table , 

var  state-parameter 

map (Table , 

var  state-gucird 

map (Table , 

var  next-state 

map (Table , 

var  state-action 

map (Table , 

var  num-real 

map (Table , 

var  num-int 

map (Table , 

Identifier)  =  {||} 
Identifier)  =  {11} 
seq(StateEntry) )  =  {||} 
Identifier)  =  {||} 
Identifier)  =  {| 1} 
seqddentif  ier))  =  {11} 
Identifier)  =  { I  I } 
Identifier)  =  {||} 
Identifier)  =  { I  I } 
real)  =  {] 1} 
integer)  =  { I  I } 
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I - 

y,  structure  for  Abstract  Syntax  Tree 

I - 

form  Def ine-Tree-Attributes-of-State-Table 

Define-Tree-Attributes( ’StateTable,  {’table-name,  ’table-label, 

’state-entries})  & 

Define-Tree-Attributes( ’StateEntry,  {’current-state ,  ’state-event , 

’state-parameter, ’state-guard, 
’next-state,  ’state-action}) 


I - 

y,  STT  Grammar  Definition 

I - 

! ! in-grammar ( ’ syntax) 
grammar  STT 

start-classes  StateTable 
file-classes  StateTable 
no-patterns 

case-sensitive 
symbol -continue-chars 

"abcdefghijklmnopqrstuvwxyzABCDEFGHIJK.LMN0PQRSTUVWXYZ0123456789._-=\\$()<>" 

symbol-start-chars 

"abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMN0PQRS’nJVWXyZ0123456789_$(" 

productions 

StateTable  ::=  ["\\begin{table} [htb] " 

"\\caption{"  table-name  "}" 

"\\vspace*{.2in}" 

"\\label{"  table-label  "}" 

"Wcentering" 

"\\begin{tabular}{ 1 1 1 1 1 1 1 1 1  1 1 1 1 1 }" 

"Whline" 

"Current"  "Event"  "&"  "Parameters"  "Guard"  "&" 

"Next"  "&"  "ActionWW" 

" \ \hl ine \\hl ine " 
state-entries  +  "" 

"WhlineWhline" 

"\\end{tabular}" 

"\\end{table}"]  builds  StateTable, 

StateEntry  : :=  [current-state  state-event  state-pareimeter  *  "" 

{state-guard}  next-state  {state-action} 

"\\\\"  {"Whline"}]  builds  StateEntry, 

Identifier  : :=  [(name  |  num-int  I  num-real)]  builds  identifier 

end 
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Appendix  G.  UZed  Domain  Model 


This  appendix  contains  the  graphical  models  of  the  UZed  extensions  (including  the 
Mathematical  Toolkit)  to  the  unified  domain  model.  These  models  form  the  basis  for 
future  semantic  analysis  tasks  to  reduce  the  language  specific  notations  into  a  canonical 
format.  This  task  can  be  accomplished  by  extending  the  unified  abstract  framework  using 
pattern  matching  and  term  rewriting  on  the  Larch  and  Z  specific  object  classes. 


G.l  UZed  Extensions 


Figure  G.l  UZed  Domain  Theory  Model 
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Figure  G.3  U^ed  External  References 
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Figure  G.4  Z  Axioms  (1  of  5) 


Figure  G.5  Z  Axioms  (2  of  5) 
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Figure  G.6  Z  Axioms  (3  of  5) 


Figure  G.7  Z  Axioms  (4  of  5) 


G-5 


NEGA' 

PRE 

_ _ 

PED- 

D 

PREDICATE-1 

CONJUNCT- 

PRED 

DISJUNCT- 

PRED 

5 


IMPLICATION- 

PRED 

PREDICATE-1 

PREDICATE-1 

Figure  G.8  Z  Axioms  (5  of  5) 
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EXPRESSION 


Figure  G.9  ^Expressions  (1  of  7) 


Figure  G.IO  Z  Expressions  (2  of  7) 


G-7 


EXPRESSION-1 


Figure  G.ll  Z  Expressions  (3  of  7) 


Figure  G.12  Z  Expressions  (4  of  7) 
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Figure  G.13  Z  Expressions  (5  of  7) 


(FIGURE  G.15) 


Figure  G.14  Z  Expressions  (6  of  7) 
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Figure  G.15  ^Expressions  (7  of  7) 


Figure  G.16  Core  Z  Symbols 
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Figure  G.17  Definition  Theory  Model  (1  of  3) 
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Figure  G.18  Definition  Theory  Model  (2  of  3) 
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Figure  G.19  Definition  Theory  Model  (3  of  3) 
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Figure  G.20  Schema  Calculus  Expressions  (1  of  4) 


Figure  G.21  Schema  Calculus  Expressions  (2  of  4) 
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Figure  G.22  Schema  Calculus  Expressions  (3  of  4) 


Figure  G.23  Schema  Calculus  Expressions  (4  of  4) 
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G.2  Unified  ToolKit 


Figure  G.24  ToolKit  Domain  Model 
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Appendix  H.  REFINE  Code  for  the  UZed  Domain  Model 

This  appendix  contains  the  Rbfine  code  for  the  UZed  domain  model  plus  ToolKit. 
The  original  Z  domain  model  was  revised  to  use  the  core  unified  domain  model  object 
classes  and  map  attributes.  The  UZed  extensions  include  Z  specific  syntax  that  are  spe¬ 
cializations  of  a  unified  parent  object  class  found  in  the  Unified  Domain  Model. 


H.l  UZed  Domain  Model 

!!  in-package ("RU") 

!!  in-grammar (’user) 

#1  I 

File  name:  uzed-dm.re 

Description:  This  file  defines  am.  object  model  for  the  UZed  language  and 
constructs  an  AST  for  an  input  specification  written  in  LaTeX. 

I  I# 


- 

'/,  Unified  Domain  Model  Object  Class  Declarations 

y - 

var  Unif ied-Object 


var  DomainTheory 


object-class  subtype-of  user-object 
object-class  subtype-of  Unif ied-Object 


var  DomainTheoryTypes 
var  ObjectTheory 
var  DynamicTheory 
var  FunctionalTheory 


:  object-class  subtype-of  Unif ied-Object 
:  object-class  subtype-of  DomainTheoryTypes 
:  object-class  subtype-of  DomainTheoryTypes 
:  object-class  subtype-of  DomainTheoryTypes 


var  Theoryld 

var  ObjectTheory Id 
var  DyneimicTheoryld 
var  FunctionalTheoryld 


:  object-class  subtype-of  Unif ied-Object 
:  object-class  subtype-of  Theoryld 
:  object-class  subtype-of  Theoryld 
:  object-class  subtype-of  Theoryld 


var  TheoryBody 

var  ObjectTheoryBody 
var  DynamicTheoryBody 
var  FunctionalTheoryBody 


:  object-class  subtype-of  Unif ied-Object 
:  object-class  subtype-of  TheoryBody 
:  object-class  subtype-of  TheoryBody 
:  object-class  subtype-of  TheoryBody 


var  TheoryDecl 

var  ObjectTheoryDecl 
var  DynamicTheoryDecl 
var  FunctionalTheoryDecl 


:  object-class  subtype-of  Unified-Object 
:  object-class  subtype-of  TheoryDecl 
:  object-class  subtype-of  TheoryDecl 
:  object-class  subtype-of  TheoryDecl 
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var  SignatureDecl 
var  ExternalRef 


;  object-class  subtype-of  Unified-Object 
;  object-class  subtype-of  Unified-Object 


var  TheoryAxioms 

var  ObjectTheoryAxioms 
var  DynamicTheoryAxioms 
var  FunctionalTheoryAxioms 


:  object-class  subtype-of  Unified-Object 
:  object-class  subtype-of  TheoryAxioms 
:  object-class  subtype-of  TheoryAxioms 
:  object-class  subtype-of  TheoryAxioms 


I - 

'/,  Zed  Specific  Object  Class  Declarations 

I - 


var  StateTheory 
var  EventTheory 


object-class  subtype-of  DynaraicTheory 
object-class  subtype-of  DynamicTheory 


var  Def initionTheory 

var  BasicTypesDefinition 
var  DataTypesDefinition 
var  AxiomaticDef inition 
var  GenericDef inition 
var  SchemaExpressions 
var  GlobalConstants 


object-class  subtype-of 
:  object-class  subtype 
:  object-class  subtype- 
:  object-class  subtype- 
:  object-class  subtype- 
;  object-class  subtype- 
;  object-class  subtype- 


DomainThe  oryType  s 
of  Def initionTheory 
of  Def initionTheory 
of  Def initionTheory 
of  Def initionTheory 
of  Def initionTheory 
of  Def initionTheory 


var  StateTheoryBody 
var  EventTheoryBody 


object-class  subtype-of  DynamicTheoryBody 
object-class  subtype-of  DynamicTheoryBody 


var 

ZedEnviron 

:  object-class 

subtype-of 

TheoryBody 

var 

SyntaxEnviron 

:  object-class 

subtype-of 

TheoryBody 

var 

AxiomaticBox 

:  object-class 

subtype-of 

TheoryBody 

var 

GenericBox 

:  object-class 

subtype-of 

TheoryBody 

var 

SchemaExpDef 

:  object-class 

subtype-of 

TheoryBody 

var 

ConstantConstruct 

:  object-class 

subt3rpe-of 

TheoryBody 

var 

Axiomat icDef De  c 1 

:  object-class 

subtype-of 

TheoryDecl 

var 

AxiomaticDef Axioms 

:  object-class 

subtype-of 

TheoryAxioms 

var 

GenericDefDecl 

:  object-class 

subtype-of 

TheoryDecl 

var 

GenericDef Axioms 

:  object-class 

subtype-of 

TheoryAxioms 

var 

StateTheoryDecl 

:  object-class 

subtype-of 

DynamicTheoryDecl 

var 

St at  eThe  oryAxioms 

:  object-class 

subtype-of 

DynamicTheoryAxioms 

var 

EventTheoryDecl 

:  object-class 

subtype-of 

DynamicTheoryDecl 

var  EventTheoryDecll 
var  EventTheoryDecl2 
var  EventTheoryAxioms 

var  Def-Lhs 
var  Def-Lhs 1 


:  object-class  subtype-of  EventTheoryDecl 
:  object-class  subtype-of  EventTheoryDecl 
:  object-class  subtype-of  DynamicTheoryAxioms 

object-class  subtype-of  Unified-Object 
:  object-class  subtype-of  Def-Lhs 


var  SchemaText 


object-class  subtype-of  Unified-Object 
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var  SchemaRef 
var  SchemaRef 1 

var  UndecoratedSchema 
var  DecoratedSchema 
var  SchemaRef 2 
var  DeltaSchema 
var  XiSchema 


:  object-class  subtype-of  ExternalRef 
;  object-class  subtype-of  ExternalRef 
:  object-class  subtype-of  SchemaRefl 
:  object-class  subtype-of  SchemaRefl 
:  object-class  subtype-of  ExternalRef 
:  object-class  subtype-of  SchemaRef2 
:  object-class  subtype-of  SchemaRef2 


var  BasicDeclSeq 


:  object-class  subtype-of  SignatureDecl 


var  Identifier 


:  object-class  subtype-of  Unified-Object 


var  OperationName 
var  InFixOperation 
var  ImageOperation 


;  object-class  subtype-of  Unif ied-Dbject 
:  object-class  subtype-of  OperationName 
:  object-class  subtype-of  OperationName 


var  IdName 


:  object-class  subtype-of  Unified-Object 


var  Numl 
var  Num2 


:  object-class  subtype-of  Unified-Object 
:  object-class  subtype-of  Unified-Object 


var  Decoration 

var  Final-Decoration 
var  Input-Decoration 
var  Output-Decoration 


:  object-class  subtype-of  Unified-Object 
:  object-class  subtype-of  Decoration 
:  object-class  subtype-of  Decoration 
:  object-class  subtype-of  Decoration 


var  MarkerSymbol 


:  object-class  subtype-of  Unified-Object 


var  Symbols 

var  MiscSymbols 
var  InFixSymbols 
var  InRelSymbols 
var  Equality 
var  Element Of 
var  IngenSymbols 
var  InFunSymbols 
var  PreFixSymbols 
var  PreRelSymbols 
var  PreGenSymbols 
var  PostFixSymbols 
var  PostFunSymbols 


:  object-class  subtype-of  Unified-Object 
:  object-class  subtype-of  Symbols 
;  object-class  subtype-of  Symbols 

:  object-class  subtype-of  InFixSymbols 
: object-class  subtype-of  InRelSymbols 
: object-class  subtype-of  InRelSymbols 
:  object-class  subtype-of  InFixSymbols 
:  object-class  subtype-of  InFixSymbols 
:  object-class  subtype-of  Symbols 

:  object-class  subtype-of  PreFixSymbols 
:  object-class  subtype-of  PreFixSymbols 
:  object-class  subtype-of  Symbols 

:  object-class  subtype-of  PostFixSymbols 


var  SchemaExp 

var  Universal-SchemaExp 
var  Existential-SchemaExp 
var  Unique-SchemaExp 
var  SchemaExp-1 

var  SchemaText- SchemaExp 
var  SchemaRef-SchemaExp 
var  Negated-SchemaExp 


:  object-class  subtype-of  Unified-Object 
:  object-class  subtype-of  SchemaExp 
:  object-class  subtype-of  SchemaExp 
:  object-class  subtype-of  SchemaExp 
:  object-class  subtype-of  SchemaExp 
:  object-class  subtype-of  SchemaExp-1 
:  object-class  subtype-of  SchemaExp-1 
:  object-class  subtype-of  SchemaExp-1 
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var  PreCondition-SchemaExp 
var  Conjiinct-ScliemaExp 
var  Disjunct-SchemaExp 
var  Implication-SchemaExp 
var  Equivalent-SchemaExp 
var  Projection-SchemaExp 
var  Hiding-SchemaExp 
var  Composition-SchemaExp 


object-class  subtype-of  SchemaExp-1 
object-class  subtype-of  SchemaExp-1 
object-class  subtype-of  SchemaExp-1 
object-class  subtype-of  SchemaExp-1 
object-class  subtype-of  SchemaExp-1 
object-class  subtype-of  SchemaExp-1 
object-class  subtype-of  SchemaExp-1 
object-class  subtype-of  SchemaExp-1 


var  Predicate 

var  Universal-Pred 
var  Existential-Pred 
var  Unique-Pred 
var  Predicate-1 
var  True-Pred 
var  False-Pred 
var  Connect ive-Pred 
var  Negated-Pred 
var  Conjunct-Pred 
var  Disjunct-Pred 
var  Implication-Pred 
var  Equivalent-Pred 
var  Relationall-Pred 
var  Relational2-Pred 
var  Relational3-Pred 
var  PreRel-Pred 
var  SchemaRef-Pred 
var  PreSchemaRef-Pred 
var  Bracket-Pred 


:  object-class  subtype-of  Unif ied-Object 
:  object-class  subtype-of  Predicate 
:  object-class  subtype-of  Predicate 
:  object-class  subtype-of  Predicate 
;  object-class  subtype-of  Predicate 

:  object-class  subtype-of  Predicate-1 
:  object-class  subtype-of  Predicate-1 
:  object-class  subtype-of  Predicate-1 

:  object-class  subtype-of  Connective-Pred 
;  object-class  subtype-of  Connective-Pred 
:  object-class  subtype-of  Connective-Pred 
:  object-class  subtype-of  Connective-Pred 
:  object-class  subtype-of  Connective-Pred 
:  object-class  subtype-of  Predicate-1 
:  object-class  subtype-of  Predicate-1 
:  object-class  subtype-of  Predicate-1 
:  object-class  subtype-of  Predicate-1 
:  object-class  subtype-of  Predicate-1 
:  object-class  subtype-of  Predicate-1 
:  object-class  subtype-of  Predicate-1 


var  Expression-0 
var  Lambda-Expr 
var  Mu-Expr 
var  Expression 
var  InGen-Expr 
var  Carte sianProd-Expr 
var  Typed-Expr 
var  Natural-Type 
var  Positive-Type 
var  Integer-Type 
var  Real-Type 
var  Character-Type 
var  Expression-1 
var  InFiin-Expr 
var  PowerSet-Expr 
var  PreGen-Expr 
var  Negative-Expr 
var  PostFun-Expr 
var  Exponent-Expr 
var  Re 1 Image -Expr 
var  Expression-2 


:  object-class  subtype-of  Unif ied-Object 
:  object-class  subtype-of  Expression-0 
:  object-class  subtype-of  Expression-0 
:  object-class  subtype-of  Expression-0 
:  object-class  subtype-of  Expression 
:  object-class  subtype-of  Expression 
:  object-class  subtype-of  Expression 
:  object-class  subtype-of  Typed-Expr 
:  object-class  subtype-of  Typed-Expr 
;  object-class  subtype-of  Typed-Expr 
:  object-class  subtype-of  Typed-Expr 
:  object-class  subtype-of  Typed-Expr 
:  object-class  subtype-of  Expression 
:  object-class  subtype-of  Expression-1 
:  object-class  subtype-of  Expression-1 
:  object-class  subtype-of  Expression-1 
;  object-class  subtype-of  Expression-1 
:  object-class  subtype-of  Expression-1 
:  object-class  subtype-of  Expression-1 
:  object-class  subtype-of  Expression-1 
:  object-class  subtype-of  Expression-1 
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var  FunctionApp-Expr 
var  Expression-3 
var  Var-Name-Expr 
var  Op-Name-Expr 
var  Integer-Expr 
var  Real-Expr 
var  SchemaRef-Expr 
var  Set-Expression 
var  Set-Display-Expr 
var  Set-Comp-Expr 
var  Seq-Expr 
var  Bag-Expr 
var  Tuple-Expr 
var  Theta-Expr 
var  Component-Expr 


:  object-class  subtype-of  Expression-2 
;  object-class  subtype-of  Expression-2 
:  object-class  subtype-of  Expression-3 
:  object-class  subtype-of  Expression-3 
:  object-class  subtype-of  Expression-3 
:  object-class  subtype-of  Expression-3 
:  object-class  subtype-of  Expression-3 
:  object-class  subtype-of  Expression-3 
:  object-class  subtype-of  Set-Expression 
:  object-class  subtype-of  Set-Expression 
;  object-class  subtype-of  Expression-3 
:  object-class  subtype-of  Expression-3 
:  object-class  subtype-of  Expression-3 
:  object-class  subtype-of  Expression-3 
:  object-class  subtype-of  Expression-3 


I - 

y.  Unified  Model  Attribute  Declarations  for  Branches  in  Tree  Structure 

I - 

y. 

y,  The  brainches  of  the  Abstract  Syntax  Tree  represent  the  constructs  from  the 
y,  right  side  of  the  production  rules  found  in  the  grammar.  These  branches  are 
y,  annotated  with  the  name  of  the  following  REFINE  attribute  maps. 

y. 


/. - 

var  theory-types 

;  map (DomainTheory ,  set(DomainTheoryTypes)) 

computed-using  theory-types (x) 

=  {} 

var  theory-id 

:  map(Unified-Object,  IdName) 

=  {I  l> 

var  ot-id 

:  mapCDomainTheoryTypes,  IdName) 

=  {l  l> 

var  dt-id 

:  mapCDomainTheoryTypes,  IdName) 

=  {I  1} 

var  ft-id 

:  mapCDomainTheoryTypes,  IdName) 

=  {I  1} 

var  theory-body 

:  mapCDomainTheoryTypes,  TheoryBody) 

=  {|  l> 

var  ot-body 

:  mapCDomainTheoryTypes,  ObjectTheoryBody) 

=  {|l> 

var  dt-body 

:  mapCDomainTheoryTypes,  DynamicTheoryBody) 

=  {11} 

var  ft-body 

:  mapCDomainTheoryTypes,  FunctionalTheoryBody) 

=  {ll} 

var  theory-decl 

:  mapCTheoryBody ,  TheoryDecl) 

=  {|  1} 

var  external-refs 

:  mapCTheoryDecl,  setCExternalRef )) 

computed-using  external-ref sCx) 

=  {> 

var  signature-decl 

:  mapCTheoryDecl,  setCSignatureDecl)) 

computed-using  signature-decl Cx) 

=  {} 

var  theory-axioms 

0/  .  .. 

:  mapCTheoryBody,  TheoryAxioms) 

=  {l  1} 

/o 

y,  Zed  Specific  Map 
0/ 

Attributes 

/o 

var  st-id 

:  mapCDomainTheoryTypes,  IdName) 

=  {ll} 
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var  et-id 

:  mapCDomainTheoryTypes,  IdName) 

=  {l 

l> 

var  st-body 

:  mapCDomainTheoryTypes,  StateTheoryBody) 

=  {l  l> 

var  et-body 

:  mapCDomainTheoryTypes,  EventTheoryBody) 

=  {l 

1} 

var  zed-environ 

:  mapCUnified-Object,  ZedEnviron) 

=  {l 

l> 

var  syntax-environ 

:  mapCUnified-Object,  SyntaxEnviron) 

=  {I 

1} 

var  axiomatic-box 

:  mapCUnified-Object,  AxiomaticBox) 

=  {| 

1} 

var  generic-box 

:  mapCUnified-Object,  GenericBox) 

=  {|  1} 

var  schema-exp-def 

:  mapCUnified-Object,  SchemaExpDef ) 

=  {l 

1} 

var  constant-construct 

:  mapCUnif ied-Object ,  Const antConstruct) 

=  {[ 

l> 

var  obj-theory-decl 

:  mapCUnified-Object,  ObjectTheoryDecl) 

=  {l 

l> 

Vcir  obj -theory-axioms 

:  mapCUnified-Object,  ObjectTheoryAxioms) 

=  {l 

l> 

var  state-theory-decl 

:  mapCUnified-Object,  StateTheoryDecl) 

=  {l 

1} 

var  state-theory-axioms 

:  mapCUnified-Object,  StateTheoryAxioms) 

=  {l 

1} 

var  event-theory-decl 

:  mapCUnified-Object,  EventTheoryDecl) 

=  {| 

l> 

var  event -theory-axioms 

:  mapCUnified-Object,  EventTheoryAxioms) 

=  {l  l> 

var  fun-theory-decl 

:  mapCUnified-Object,  FunctionalTheoryDecl) 

=  {l 

1} 

var  fun-theory-axioms 

:  mapCUnified-Object,  FunctionalTheoryAxioms) 

=  {| 

l> 

var  axiom-dec 1-part 

:  mapCUnified-Object,  AxiomaticDefDecl) 

=  {I 

l> 

var  axiom-axiom-part 

:  mapCUnified-Object,  AxiomaticDef Axioms) 

=  {l 

1} 

var  generic-decl-part 

:  mapCUnified-Object,  GenericDefDecl) 

= 

l> 

var  generic-axiom-part 

;  mapCUnified-Object,  GenericDef Axioms) 

=  {l 

l> 

var  defs-lhs 

:  mapCUnified-Object,  Def-Lhs) 

=  {| 

1} 

var  schema-text 

:  mapCUnified-Object,  SchemaText) 

=  {I 

l> 

var  set-schema-text 

:  map CUnif ied-Object,  SchemaText) 

= 

1} 

var  schema-ref 

:  mapCUnified-Object,  SchemaRef) 

=  {l 

l> 

var  schema- inclusion 

:  mapCUnified-Object,  setCUndecoratedSchema)) 

computed-using  schema-inclusionCx) 

=  {> 

var  schema-inherit 

;  mapCUnified-Object,  setCUndecoratedSchema)) 

computed-using  schema-inherit Cx) 

=  {} 

var  any-schema2-refs 

:  mapCUnified-Object,  setCSchemaRef2)) 

computed-using  any-schema2-ref s  Cx) 

=  {} 

var  one-event-decl 

:  mapCUnified-Object,  BasicDeclSeq) 

=  {I  1} 

var  basic-decls 

:  mapCUnified-Object,  setCBasicDeclSeq)) 

computed-using  basic-decls Cx) 

=  {> 

var  axiom-decls 

:  mapCUnified-Object,  setCBasicDeclSeq)) 

computed-using  axiom-decls Cx) 

=  {} 

var  object-decls 

:  mapCUnified-Object,  setCBasicDeclSeq)) 

computed-using  object-declsCx) 

=  {} 

var  state-decls 

:  mapCUnified-Object,  setCBasicDeclSeq)) 
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computed-using  state-decls(x) 

=  {} 

var  event-decls 

:  map(Unified-Object,  set(BasicDeclSeq)) 

computed-using  event-decls (x) 

=  {} 

var  functional-decls 

:  map(Unified-Object,  set(BasicDeclSeq)) 

computed-using  functional-decls (x) 

=  {} 

var  schema-name 

:  map(Unified-Object,  Identifier) 

=  {ll} 

var  var-name 

:  mapCUnified-Object,  Identifier) 

=  {ll} 

var  def -var-name 

:  map(Unified-Object,  Identifier) 

=  -Cl  1} 

var  gen-formal s 

:  map(Unified-Object,  set (Identifier)) 

computed-using  gen-f ormals(x) 

=  {} 

var  basic-i-dents 

:  map(Unif ied-Object ,  set (Identifier)) 

computed-using  basic-i-dents (x) 

=  o 

var  ciny-op-name 

:  map (Unif ied-Object,  OperationName) 

=  {1 1} 

var  i-dent 

:  map (Unif ied-Object ,  IdName) 

=  {l  1} 

var  i-dents 

:  map(Unif ied-Object,  set(IdName)) 

computed-using  i-dents (x) 

=  {> 

var  enums 

:  map (Unif ied-Object,  set (IdName)) 

computed-using  enums (x) 

=  {} 

var  para-list 

;  map (Unif ied-Object,  set(IdName)) 

computed-using  para-list (x) 

=  {} 

var  gen-para-list 

:  map (Unif ied-Object,  set(IdName)) 

computed-using  gen-para-list (x) 

=  {> 

var  num-1 

:  map (Unif ied-Object,  integer) 

=  {ll> 

var  num-2 

:  map(Unified-Object,  real) 

=  -Cl  1} 

var  deco-ration 

:  map (Unif ied-Object,  Decoration) 

=  {ll> 

var  any-decoration 

:  map (Unif ied-Object,  Decoration) 

=  {ll> 

var  any-decs 

:  map(Unif ied-Object ,  set (Decoration)) 

computed-using  any-decs (x) 

=  {} 

var  marker 1 

:  map (Unif ied-Object,  MarkerSymbol) 

=  {ll> 

var  marker2 

:  map (Unif ied-Object,  MarkerSymbol) 

=  {l  l> 

var  any-in-fix-sym 

;  map(Unif ied-Object,  InFixSymbols) 

=  {ll} 

var  anyl-in-rel-sym 

:  map (Unif ied-Object,  InRelSymbols) 

=  {ll} 

var  any2-in-rel-sym 

:  map (Unif ied-Object,  InRelSymbols) 

=  -Cl  1} 

var  any3-in-rel-sym 

:  map (Unif ied-Object,  InRelSymbols) 

=  {l  l> 

var  any4-in-rel-sym 

:  map (Unif ied-Object,  InRelSymbols) 

=  {l  l> 

var  any-pre-rel-sym 

:  map (Unif ied-Object,  PreRelSymbols) 

=  {l  1} 

var  any-in-gen-sym 

:  map (Unif ied-Object,  InGenSymbols) 

=  {l  1} 

var  any-in-fun-sym 

:  map (Unif ied-Object,  InFunSymbols) 

=  {l  1} 

var  any-pre-gen-sym 

:  map(Unified-Object,  PreGenSymbols) 

=  {ll} 

var  any-post-fun-sym 

:  map (Unif ied-Object,  PostFunSymbols) 

=  1} 

var  schema-exp 

:  map (Unif ied-Object,  SchemaExp) 

=  {l  l> 

var  any-schema-exp 

;  map (Unif ied-Object,  SchemaExp) 

=  {ll} 

var  any-schema-expl 

:  map(Unif ied-Object,  SchemaExp-1) 

=  {ll} 
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var  anyl-schema-expl 
var  ciny2-schema-expl 


:  map(Unified-Object,  SchemaExp-1) 
:  mapCUnif ied-Object ,  SchemaExp-1) 


=  {l  l> 
=  {l  1} 


var  any-pred  :  map(Unif ied-Object ,  Predicate)  =  {| 1} 

var  any-predl  :  map(Unified-Gbject ,  Predicate-1)  =  {I  1} 

var  anyl-predl  :  map(Unif ied-Object,  Predicate-1)  =  {| 1} 

var  any2-predl  :  map(Unified-Object,  Predicate-1)  =  {||} 

var  any-preds  :  map (Unif ied-Object,  set (Predicate)) 

computed-using  any-preds (x)  =  {} 

var  any-axiom-preds  :  map (Unif ied-Object ,  set (Predicate)) 

computed-using  any-axiom-preds (x)  =  {} 

var  any-object-preds  :  map (Unif ied-Object ,  set (Predicate)) 

computed-using  any-object-preds (x)  =  {} 

var  any-state-preds  :  map (Unif ied-Object,  set (Predicate)) 

computed-using  any-state-preds (x)  =  {} 

var  ciny-event-preds  :  map (Unif ied-Object ,  set (Predicate)) 

computed-using  any-event-preds(x)  =  {} 

var  any-fun-preds  :  map (Unif ied-Object ,  set (Predicate)) 

computed-using  any-fim-preds(x)  =  {> 

var  any-post-preds  :  map (Unif ied-Object,  set (Predicate)) 

computed-using  any-post-preds (x)  =  {} 

var  state-post-preds  ;  map (Unif ied-Object,  set (Predicate)) 

computed-using  state-post-preds (x)  =  {} 

var  fun-post-preds  :  map(Unif ied-Object ,  set (Predicate)) 

computed-using  fun-post-preds (x)  =  {} 

var  any-exprO  :  map(Unified-Object,  Expression-0)  =  {11} 

var  any-expr  :  map (Unif ied-Object,  Expression)  =  {||} 

var  any-one-expr  :  map(Unified-Object,  Expression)  =  {||} 

var  any-second-expr  :  map (Unif ied-Object,  Expression)  =  {||} 

var  any-third-expr  :  map (Unif ied-Object,  Expression)  =  {l|} 

var  any-fourth-expr  :  map(Unif ied-Object,  Expression)  =  {||} 

var  any-expr-comp  :  map (Unif ied-Object ,  Expression)  =  {||> 

var  any-exprl  :  map (Unif ied-Object,  Expression-1)  =  {| 1} 

var  any-one-exprl  :  map(Unified-Object,  Expression-1)  =  {||} 

var  any-second-exprl  :  map (Unif ied-Object,  Expression-1)  =  {||} 

var  any-expr2  :  map (Unif ied-Object,  Expression-2)  =  {| 1} 

var  any-expr3  :  map(Unified-Object,  Expression-3)  =  {11} 

var  any-exprs  :  map (Unif ied-Object,  set (Expression)) 

computed-using  any-exprs (x)  =  {} 

var  gen-actual-list  :  map (Unif ied-Object,  set (Expression)) 

computed-using  gen-actual-list (x)  =  {} 

var  any-exprsl  ;  map (Unif ied-Object ,  set (Expression-1)) 

computed-using  any-exprs l(x)  =  {} 

I - 

'/,  Annotation  Attributes 

% - 

var  delta-link  :  map(BasicDeclSeq,  boolean)  =  {||} 

var  xi-link  :  map(BasicDeclSeq,  boolean)  =  {11} 
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var  inclusion-link 
var  inherit-link 


:  map(BasicDeclSeq,  boolean) 
;  mapCBasicDeclSeq,  boolean) 


=  {ll} 

=  {l  1} 


I - 

’/,  Define  Structure  of  Abstract  Syntax  Tree 

I - 

form  Def ine-Tree-Attributes-of-Unif ied- Specif icat ion 

Define-Tree-Attributes('DomainTheory,  {’theory-types})  & 
Define-Tree-Attributes(’ObjectTheory,  {’ot-id,  ’ot-body})  & 
Define-Tree-Attributes(’DynamicTheory,  {’dt-id,  ’dt-body>)  k 
Define-Tree-Attributes(’FunctionalTheory,  {’ft-id,  ’ft-body})  k 

Define-Tree-Attributes( ’TheoryBody,  {’theory-decl,  ’theory-axioms})  k 

Def ine-Tree-Attributes( ’TheoryDecl,  {’signature-decl,  ’external-refs})  k 


I - 

7,  Zed  Specific  AST  Structures 

% - 

Def ine-Tree-Attributes( ’StateTheory ,  {’st-id,  ’st-body})  k 
Define-Tree-Attributes( ’EventTheory ,  {’et-id,  ’et-body})  k 

Define-Tree-Attributes( ’BasicTypesDefinition,  {’zed-environ})  k 
Define-Tree-Attributes( ’DataTypesDefinition,  {’syntax-environ})  k 
Define-Tree-Attributes( ’AxiomaticDefinition,  {’axiomatic-box})  k 
Def ine-Tree-Attributes( ’GenericDefinition,  {’generic-box})  k 
Def ine-Tree-Attributes( ’SchemaExpressions,  {’ schema-exp-def })  k 
Def ine-Tree-Attributes( ’GlobalConstants,  {’constant-construct})  & 


Def ine-Tree-Attributes ( ’ Ob j  ectTheoryBody ,  { ’ ob j -theory-decl , 

’obj -theory-axioms})  k 

Def ine-Tree-Attributes( ’StateTheoryBody ,  {’ state -theory-decl , 

’state-theory-axioms})  & 

Def ine-Tree-Attr ibutes ( ’ EventTheoryBody ,  { ’ event -theory-decl , 

’event -theory-axioms})  k 

Def ine-Tree-Attr ibutes ( ’FunctionalTheoryBody,  {’fun-theory-decl , 

’fun-theory-axioms})  k 


Def ine-Tree-Attributes( ’ZedEnviron,  {’i-dents})  k 
Define-Tree-Attributes( ’SyntaxEnviron,  {’i-dent,  ’enums})  k 
Define-Tree-Attributes( ’AxiomaticBox,  {’axiom-decl-part , 

’axiom-axiom-part})  k 

Def ine-Tree-Attributes( ’GenericBox,  {’para-list ,  ’generic-decl-part , 

’generic-axiom-part})  k 

Define-Tree-Attributes(’SchemaExpDef ,  {’theory-id,  ’gen-formals, 

’schema-exp})  k 

Define-Tree-Attributes(’ConstantConstruct,  {’defs-lhs,  ’any-expr})  k 
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Def ine-Tree-Attributes( ’ AxiomaticDefDecl,  {’axiom-decls, 

’schema-inclusion})  & 

Define-Tree-Attributes(’AxiomaticDefAxioms,  {’any-axiom-preds})  & 

Define-Tree-Attributes( ’GenericDefDecl,  {’basic-decls, 

’schema-inclusion})  & 

Define-Tree-Attributes(’GenericDef Axioms,  {’any-preds})  & 

Def ine-Tree-Attributes ( ’ Ob j ectTheoryDecl ,  { ’ ob j  ect-decls , 

’schema-inherit})  & 

Def ine-Tree-Attributes ( ’ Obj ectTheoryAxioms ,  { ’ any-ob j ect-preds})  & 

Def ine-Tree-Attributes( ’StateTheoryDecl,  ■[’ schema- inclusion, 

’state-decls})  & 

Define-Tree-Attributes( ’StateTheoryAxioms,  {’any-state-preds, 

’state-post-preds})  & 

Define-Tree-Attributes(’EventTheoryDecll,  {’one-event-decl})  & 
Define-Tree-Attributes(’EventTheoryDecl2,  {’event-decls})  & 
Define-Tree-Attributes(’EventTheoryAxioms,  {’any-event-preds})  & 


Def ine-Tree-Attributes ( ’ FunctionalTheoryDecl ,  { ’ any-schema2-ref s , 

’functional-decls})  & 

Define-Tree-Attributes( ’FunctionalTheory Axioms,  {’any-fun-preds, 

’fun-post-preds})  Sc 

Define-Tree-Attributes(’Def-Lhsl,  {’def-var-name ,  ’gen-para-list})  Sc 

Define-Tree-Attributes(’SchemaText,  {’basic-decls,  ’any-pred})  Sc 
Define-Tree-Attributes(’SchemaRef ,  {’schema-name})  Sc 

Def ine-Tree-Attributes( ’UndecoratedSchema,  {’theory-id})  Sc 
Define-Tree-Attributes(’DecoratedSchema,  {’theory-id,  ’any-decs})  Sc 
Def ine-Tree-Attributes( ’DeltaSchema,  {’theory-id})  Sc 
Define-Tree-Attributes(’XiSchema,  {’theory-id})  & 

Def ine-Tree-Attributes( ’BasicDeclSeq,  {’basic-i-dents,  ’any-expr})  Sc 

Define-Tree-Attributes( ’Identifier,  {’i-dent,  ’any-decoration})  Sc 

Define-Tree-Attributes( ’InFixOperation,  {’markerl ,  ’any-in-fix-sym, 

’marker2})  Sc 

Define-Tree-Attributes(’ImageOperation,  {’markerl,  ’marker2})  & 


5^ - 

’/,  ASTs  for  Schema  Calculus  Expressions 

I - 

Def ine-Tree-Attributes ( ’Universal-SchemaExp,  {’schema-text , 
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’any-schema-exp})  & 

Define-Tree-Attributes( ’Existent ial-SchemaExp,  {’schema-text , 

’any-schema-exp})  & 

Define-Tree-Attributes( ’Unique-SchemaExp,  {’schema-text,  ’any-schema-exp})  & 
Define-Tree-Attributes( ’SchemaText-SchemaExp,  {’schema-text})  & 

Def ine-Tree-Attributes( ’SchemaEef-SchemaExp,  {’schema-ref})  & 
Define-Tree-Attributes( ’Negated-SchemaExp,  {’any-schema-expl})  & 
Define-Tree-Attributes( ’PreCondition-SchemaExp,  {’any-schema-expl})  & 
Define-Tree-Attributes( ’Conjunct-SchemaExp,  {’anyl-schema-expl , 

’any2-schema-expl})  & 

Define-Tree-Attributes(’Disjunct-SchemaExp,  {’anyl-schema-expl , 

’any2-schema-expl})  & 

Def ine-Tree-Attributes ( ’ Implication-SchemaExp ,  { ’ anyl-schema-expl , 

’any2-schema-expl})  & 

Define-Tree-Attributes( ’Equivalent-SchemaExp,  {’anyl-schema-expl, 

’any2-schema-expl})  & 

Define-Tree-Attributes( ’Projection-SchemciExp,  {’anyl-schema-expl , 

’any2-schema-expl})  & 

Define-Tree-Attributes( ’Hiding-SchemaExp,  {’any-schema-expl , 

’basic-i-dents})  & 

Def ine-Tree-Attributes ( ’Composition-SchemaExp,  {’anyl-schema-expl , 

’any2-schema-expl})  & 


% - 

*/,  ASTs  for  Predicates 

I - 

Define-Tree-Attributes( ’Universal-Pred,  {’schema-text,  ’any-pred})  & 
Define-Tree-Attributes( ’Existential-Pred,  {’schema-text,  ’any-pred})  & 

Def ine-Tree-Attributes( ’Unique-Pred,  {’schema-text,  ’any-pred})  & 

Def ine-Tree-Attributes ( ’True-Pred,  {’i-dent})  & 

Def ine-Tree-Attributes ( ’False-Pred,  {’i-dent})  & 
Define-Tree-Attributes(’Negated-Pred,  {’any-predl})  & 

Define-Tree-Attributes( ’Conjunct-Pred,  {’anyl-predl ,  ’any2-predl})  & 
Define-Tree-Attributes( ’Disj\inct-Pred,  {’anyl-predl,  ’any2-predl})  & 
Define-Tree-Attributes( ’Implication-Pred,  {’anyl-predl,  ’any2-predl})  & 
Define-Tree-Attributes( ’Equivalent-Pred,  {’anyl-predl,  ’any2-predl})  & 
Define-Tree-Attributes( ’Relationall-Pred,  {’any-one-expr ,  ’anyl-in-rel-sym, 

’any-second-expr})  & 

Define-Tree-Attributes( ’Relational2-Pred,  {’any-one-expr,  ’anyl-in-rel-sym, 

’any-second-expr,  ’any2-in-rel-sym 
’any-third-expr})  & 

Define-Tree-Attributes( ’Relational3-Pred,  {’any-one-expr,  ’anyl-in-rel-sym, 

’any-second-expr,  ’any2-in-rel-sym 
’any-third-expr,  ’any3-in-rel-sym, 
’any-f ourth-expr})  & 

Define-Tree-Attributes( ’PreRel-Pred,  {’any-pre-rel-sym,  ’any-expr})  & 
Define-Tree-Attributes( ’SchemaRef-Pred,  {’schema-ref})  & 
Define-Tree-Attributes( ’PreSchemaRef-Pred,  {’schema-ref})  & 
Define-Tree-Attributes( ’Bracket-Pred,  {’any-pred})  & 


%  ASTs  for  Expressions 

^ - 

Define-Tree-Attributes('Lambda-Expr,  schema-text,  ’any-expr})  & 
Define-Tree-Attributes( ’Mu-Expr ,  {’schema-text,  ’any-expr})  & 
Define-Tree-Attributes( ’InGen-Expr,  {’any-one-expr ,  ’any-in-gen-sym, 

’any-second-expr})  & 

Define-Tree-Attributes( ’CartesianProd-Expr,  {’any-exprsl})  & 
Define-Tree-AttributesC’InFun-Expr,  {’any-one-exprl ,  ’any- in-fun- sym, 

’any-second-exprl})  & 

Define-Tree-Attributes(’PowerSet-Expr,  {’any-expr3})  & 
Define-Tree-Attributes(’PreGen-Expr,  {’any-pre-gen-sym,  ’any-expr3})  k 
Define-Tree-Attributes(’Negative-Expr,  {’any-expr3>)  k 

Define-Tree-Attributes(’PostFun-Expr,  {’any-expr3,  ’any-post-fun-sym>)  k 
Define-Tree-Attributes( ’Exponent-Expr,  {’any-expr3,  ’any-expr})  k 
Define-Tree-Attributes(’RelImage-Expr,  {’any-expr3,  ’any-exprO>)  k 
Define-Tree-Attributes(’FunctionApp-Expr,  {’any-expr2,  ’any-expr3})  k 
Define-Tree-Attributes( ’Var-Name-Expr,  {’var-name,  ’gen-actual-list})  k 
Define-Tree-Attributes( ’Op-Name-Expr,  {’any-op-name})  k 
Define-Tree-Attributes(’Integer-Expr,  {’num-1})  k 
Define-Tree-Attributes(’Real-Expr,  {’num-2})  k 
Def ine-Tree-Attributes( ’Set-Display-Expr ,  {’any-exprs})  k 
Define-Tree-Attributes( ’Set-Comp-Expr ,  {’set-schema-text,  ’any-expr})  k 
Define-Tree-Attributes(’Seq-Expr,  {’any-exprs})  k 
Define-Tree-Attributes( ’Bag-Expr ,  {’any-exprs})  k 
Define-Tree-Attributes(’Tuple-Expr,  {’any-exprs})  k 
Define-Tree-Attributes(’Theta-Expr,  {’theory-id,  ’deco-ration})  k 
Define-Tree-Attributes( ’Component-Expr,  {’any-expr3,  ’i-dent}) 
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H.2  UToolKit  Domain  Model 


!!  in-package ("RU") 

!!  in-grammar ( ’user) 

#1  I 

File  name:  utoolkit-dm.re 

Description:  This  file  defines  an  object  model  for  the  Unified  Mathematical 
Toolkit  used  in  conjunction  with  the  UZed  Icinguage.  This  Toolkit  contains 
mathematically  simplistic  data  types  which  can  be  used  to  describe  many 
different  information  structures.  The  ASTs  constructed  in  this  program 
are  automatically  appended  to  the  core  UZed  language  tree  whenever  a  Toolkit 
element  is  processed  by  the  parser. 

I  I# 


I - 

'/,  Toolkit  Object  Class  Declarations 
- 


var  PreFixOperation 
var  PostFixOperation 


:  object-class  subtype-of  OperationName 
:  object-class  subtype-of  OperationName 


var  SetAlgebraSymbols 
var  PairFirst 
var  PairSecond 
var  EmptySet 
var  GeneralUnion 
var  Generalintersect 


:  object-class  subtype-of  MiscSymbols 

:  object-class  subtype-of  SetAlgebraSymbols 
:  object-class  subtype-of  SetAlgebraSymbols 
:  object-class  subtype-of  SetAlgebraSymbols 
:  object-class  subtype-of  SetAlgebraSymbols 
:  object-class  subtype-of  SetAlgebraSymbols 


var  RelationSymbols 
var  RelDomain 
var  RelRange 


:  object-class  subtype-of  MiscSymbols 

:  object-class  subtype-of  RelationSymbols 
:  object-class  subtype-of  RelationSymbols 


Vcir  FunctionSymbols 


:  object-class  subtype-of  MiscSymbols 


var  NumberSymbols 
var  Successor 
var  Cardinality 
var  Minimiim 
var  Maximum 


:  object-class  subtype-of  MiscSymbols 
:  object-class  subtype-of  NumberSymbols 
:  object-class  subtype-of  NumberSymbols 
:  object-class  subtype-of  NumberSymbols 
:  object-class  subtype-of  NumberSymbols 


var  SequenceSymbols 
var  HeadSeq 
var  LastSeq 
var  TailSeq 
var  FrontSeq 


:  object-class  subtype-of  MiscSymbols 

:  object-class  subtype-of  SequenceSymbols 
:  object-class  subtype-of  SequenceSymbols 
:  object-class  subtype-of  SequenceSymbols 
:  object-class  subtype-of  SequenceSymbols 


var  BagSymbols 
var  BagCount 
var  Bagitems 


:  object-class  subtype-of  MiscSymbols 
:  object-class  subtype-of  BagSymbols 
:  object-class  subtype-of  BagSymbols 
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var 

NotEquality 

object-class 

subtype-of 

InRelSymbols 

var 

NotElementOf 

object-class 

subtype-of 

InRelSymbols 

var 

Z-Subset 

object-class 

subtype-of 

InRelSymbols 

var 

PropSubset 

object-class 

subtype-of 

InRelSymbols 

var 

LessThan 

object-class 

subtype-of 

InRelSymbols 

var 

GreaterThan 

object-class 

subtype-of 

InRelSymbols 

var 

LessThanEq 

object-class 

subtype-of 

InRelSymbols 

var 

GreaterThanEq 

object-class 

subtype-of 

InRelSymbols 

var 

Partition 

object-class 

subtype-of 

InRelSymbols 

var 

InBag 

object-class 

subtype-of 

InRelSymbols 

var 

DisjointSet 

object-class 

subtype-of 

PreRelSymbols 

var 

Relation 

object-class 

subtype-of 

InGenSymbols 

var 

Z-Function 

object-class 

subtype-of 

InGenSymbols 

var 

PaxtialFun 

object-class 

subtype-of 

InGenSymbols 

var 

Injection 

object-class 

subtype-of 

InGenSymbols 

var 

Partialinject 

object-class 

subtype-of 

InGenSymbols 

var 

Surjection 

object-class 

subtype-of 

InGenSymbols 

var 

PartialSur ject 

object-class 

subtype-of 

InGenSymbols 

var 

Bijection 

object-class 

subtype-of 

InGenSymbols 

var 

FinitePartFun 

object-class 

subtype-of 

InGenSymbols 

var 

FinitePart Inject 

object-class 

subtype-of 

InGenSymbols 

var 

Mapping 

object-class 

subtype-of 

InFunSymbols 

var 

NumRange 

object-class 

subtype-of 

InFunSymbols 

var 

Addition 

object-class 

subtype-of 

InFunSymbols 

var 

Subtraction 

object-class 

subtype-of 

InFunSymbols 

var 

SetUnion 

object-class 

subtype-of 

InFunSymbols 

var 

SetMinus 

object-class 

subtype-of 

InFunSymbols 

var 

Concatenation 

object-class 

subtype-of 

InFunSymbols 

var 

BagUnion 

object-class 

subtype-of 

InFunSymbols 

var 

Multiplication 

object-class 

subtype-of 

InFunSymbols 

var 

Division 

object-class 

subtype-of 

InFunSymbols 

var 

Modulo 

object-class 

subtype-of 

InFunSymbols 

var 

Setintersect 

object-class 

subtype-of 

InFunSymbols 

var 

Filtering 

object-class 

subtype-of 

InFunSymbols 

var 

Composition 

object-class 

subtype-of 

InFunSymbols 

var 

BackCompose 

object-class 

subtype-of 

InFunSymbols 

var 

OverRiding 

object-class 

subtype-of 

InFunSymbols 

var 

DomainRes 

object-class 

subtype-of 

InFunSymbols 

var 

RangeRes 

object-class 

subtype-of 

InFunSymbols 

var 

AntiDomRes 

object-class 

subtype-of 

InFunSymbols 

var 

AntiRangeRes 

object-class 

subtype-of 

InFunSymbols 

var 

NonEmpty 

object-class 

subtype-of 

PreGenSymbols 

var 

IdRelation 

object-class 

subtype-of 

PreGenSymbols 

var 

FiniteSet 

object-class 

subtype-of 

PreGenSymbols 

var 

NEFinite 

object-class 

subtype-of 

PreGenSymbols 

var 

Sequence 

object-class 

subtype-of 

PreGenSymbols 
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var  NESeq 
Vcir  InjSeq 
var  Z-Bag 


:  object-class  subtype-of  PreGenSymbols 
:  object-class  subtype-of  PreGenSymbols 
:  object-class  subtype-of  PreGenSymbols 


var  Inversion 
var  TransClosure 
var  RefClosure 
’/.var  Iteration 


:  object-class  subtype-of  PostFunSymbols 
:  object-class  subtype-of  PostFunSymbols 
:  object-class  subtype-of  PostFunSymbols 
:  object-class  subtype-of  PostFunSymbols 


5^ - 

°/« - Predicate  &  Expression  Objects 

I - 


var  DisjointSet-Pred 


:  object-class  subtype-of  PreRel-Pred 


var  Misc-Expr 

var  SetAlgebra-Expr 
var  PairFirst-Expr 
var  PairSecond-Expr 
var  EmptySet-Expr 
var  GeneralUnion-Expr 
vax  Generalintersect-Expr 
var  Relations-Expr 
var  RelDomain-Expr 
var  RelRange-Expr 
var  Number-Expr 

var  Cardinality-Expr 
var  Successor-Expr 
var  MinNumber-Expr 
var  MaxN\imber-Expr 


object-class  subt3rpe-of  Expression 
:  object-class  subtype-of  Misc-Expr 

:  object-class  subtype-of  SetAlgebra-Expr 
:  object-class  subtype-of  SetAlgebra-Expr 
:  object-class  subtype-of  SetAlgebra-Expr 
:  object-class  subtype-of  SetAlgebra-Expr 
:  object-class  subt3rpe-of  SetAlgebra-Expr 
:  object-class  subtype-of  Misc-Expr 

:  object-class  subtype-of  Relations-Expr 
:  object-class  subtype-of  Relations-Expr 
:  object-class  subtype-of  Misc-Expr 
:  object-class  subtype-of  Number-Expr 
:  object-class  subtype-of  Number-Expr 
:  object-class  subtype-of  Number-Expr 
:  object-class  subtype-of  Number-Expr 


var  Relation-Expr 
var  Z-Function-Expr 
var  PartialFun-Expr 
var  Injection-Expr 
var  Partialinject-Expr 
var  Surjection-Expr 
var  PartialSurject-Expr 
var  Bijection-Expr 
var  FinitePartFun-Expr 
var  FinitePartInject-Expr 


object-class 

object-class 

object-class 

object-class 

object-class 

object-class 

object-class 

object-class 

object-class 

object-class 


subtype-of 

subtype-of 

subtype-of 

subtype-of 

subtype-of 

subtype-of 

subtype-of 

subtype-of 

subtype-of 

subtype-of 


InGen-Expr 

InGen-Expr 

InGen-Expr 

InGen-Expr 

InGen-Expr 

InGen-Expr 

InGen-Expr 

InGen-Expr 

InGen-Expr 

InGen-Expr 


var  Mapping-Expr 
var  NumRange-Expr 
var  Addition-Expr 
var  Subtract ion-Expr 
var  SetUnion-Expr 
var  SetMinus-Expr 
var  Concatenation-Expr 
var  BagUnion-Expr 
var  Multiplication-Expr 


object-class 

object-class 

object-class 

object-class 

object-class 

object-class 

object-class 

object-class 

object-class 


subtype-of 

subtype-of 

subtype-of 

subtype-of 

subtype-of 

subtype-of 

subtype-of 

subtype-of 

subtype-of 


InFun-Expr 

InFun-Expr 

InFun-Expr 

InFun-Expr 

InFun-Expr 

InFun-Expr 

InFun-Expr 

InFun-Expr 

InFun-Expr 
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var  Division-Expr 
var  Modulo-Expr 
var  Setlntersect-Expr 
var  Filtering-Expr 
var  Composition-Expr 
var  BackCompose-Expr 
var  OverRiding-Expr 
var  DomainRes-Expr 
var  RangeRes-Expr 
var  AntiDomRes-Expr 
var  AntiRcOigeRes-Expr 


object-class 

object-class 

object-class 

object-class 

object-class 

object-class 

object-class 

object-class 

object-class 

object-class 

object-class 


sTibtype-of 

subtype-of 

subtype-of 

subtype-of 

subtype-of 

subtype-of 

subtype-of 

subtype-of 

subtype-of 

subtype-of 

subtype-of 


InFun-Expr 

InFun-Expr 

InFun-Expr 

InFun-Expr 

InFun-Expr 

InFun-Expr 

InFun-Expr 

InFun-Expr 

InFun-Expr 

InFun-Expr 

InFun-Expr 


var  NonEmpty-Expr 
var  IdRelation-Expr 
var  FiniteSet-Expr 
var  MEFinite-Expr 
var  Sequence-Expr 
var  MESeq-Expr 
var  In j  Seq-Expr 
var  Z-Bag-Expr 


object-class 

object-class 

object-class 

object-class 

object-class 

object-class 

object-class 

object-class 


subtype-of 

subtype-of 

subtype-of 

subtype-of 

subtype-of 

subtype-of 

subtype-of 

subtype-of 


PreGen-Expr 

PreGen-Expr 

PreGen-Expr 

PreGen-Expr 

PreGen-Expr 

PreGen-Expr 

PreGen-Expr 

PreGen-Expr 


var  Inversion-Expr 
var  TransClosure-Expr 
var  RefClosure-Expr 


object-class 

object-class 

object-class 


subtype-of  PostFun-Expr 
subtype-of  PostFun-Expr 
subtype-of  PostFiin-Expr 


I - 

*/,  ToolKit  Attribute  Declarations  for  Branches  in  Tree  Structure 

I - 


var  any-misc-sym 
var  any-pre-f ix-sym 
var  any-post-f ix-sym 


:  map(Unified-Object, 
:  map(Unif ied-Object , 
:  map (Unif ied-Object , 


MiscSymbols)  =  {I  1} 
PreFixSymbols)  =  {||} 
PostFixSymbols)  =  {||} 


I - 

’/,  Define  Structure  of  ToolKit  Abstract  Syntax  Tree 

I - 

form  Define-Tree-Attributes-of -Zed-Specification 

Def ine-Tree-Attributes( ’PreFixOperation,  {'any-pre-f ix-sym, 

'markerl})  & 

Def ine-Tree-Attributes( 'PostFixOperation,  {'markerl , 

'any-post-f ix-sym})  & 


I - 

'/,  ASTs  for  Predicates 

% - 

Define-Tree-Attributes('DisjointSet-Pred,  {'any-expr})  & 


% - 

'/,  ASTs  for  Expressions 
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% - 

Def ine-Tree-Attributes( ’RelDomain-Expr ,  {’any-expr})  & 
Define-Tree-Attributes( ’RelRange-Expr,  {’any-expr})  & 
Define-Tree-AttributesC’Cardinality-Expr,  {’any-expr})  & 

Def ine-Tree-AttributesC’Relation-Expr,  {’any-one-expr , 

’any-second-expr})  & 

Def ine-Tree-Attributes ( ’ Z-Function-Expr ,  { ’ any-one-expr , 

’any-second-expr})  & 

Def ine-Tree-Attributes ( ’ Part ialFun-Expr ,  { ’ any-one-expr , 

’any-second-expr})  & 

Def ine-Tree-Attributes ( ’ Inj  ection-Expr ,  { ’ any-one-expr , 

’any-second-expr})  & 

Def ine-Tree-Attributes ( ’Partialinject-Expr ,  { ’ any-one-expr , 

’any-second-expr})  & 

Define-Tree-Attributes( ’Surj ection-Expr ,  {’any-one-expr, 

’any-second-expr})  & 

Def ine-Tree-Attributes ( ’PartialSur j ect-Expr ,  { ’ any-one-expr , 

’any-second-expr})  & 

Def ine-Tree-Attributes ( ’ Bij ection-Expr ,  { ’ any-one-expr , 

’any-second-expr})  & 

Def ine-Tree-Attr ibutes ( ’ Finit ePartFun-Expr ,  { ’ any-one-expr , 

’any-second-expr})  & 

Def ine-Tree-Attributes ( ’ FinitePartInj ect-Expr ,  { ’ any-one-expr , 

’any-second-expr})  & 

Define-Tree-Attributes( ’Mapping-Expr,  {’ any-one-expr 1 , 

’any-second-exprl})  & 

Def ine-Tree-Attributes ( ’ NuraRange-Expr ,  { ’ any-one-expr 1 , 

’any-second-exprl})  & 

Def ine-Tree-Attributes( ’Addition-Expr ,  {’ any-one-expr 1 , 

’any-second-exprl})  & 

Define-Tree-Attributes( ’Subtraction-Expr,  {’ any-one-expr 1 , 

’any-second-exprl})  & 

Define-Tree-Attributes( ’SetUnion-Expr,  {’ any-one-expr 1 , 

’any-second-exprl})  & 

Def ine-Tree-Attributes ( ’ SetMinus-Expr ,  { ’ any-one-expr 1 , 

’any-second-exprl})  & 

Define-Tree-Attributes( ’Concatenation-Expr ,  {’ any-one-expr 1 , 

’any-second-exprl})  & 

Define-Tree-Attributes( ’BagUnion-Expr,  {’ any-one-expr 1, 

’any-second-exprl})  & 
Define-Tree-Attributes(’Multiplication-Expr,  {’ any-one-expr 1 , 

’any-second-exprl})  & 

Define-Tree-Attributes( ’Division-Expr,  {’ any-one-expr 1 , 

’any-second-exprl})  & 

Def ine-Tree-Attributes ( ’ Modulo-Expr ,  { ’ any-one-expr 1 , 

’any-second-exprl})  & 
Define-Tree-Attributes( ’Setintersect-Expr,  {’ any-one-expr 1 , 

’any-second-exprl})  & 

Define-Tree-Attributes(’Filtering-Expr,  {’ any-one-expr 1, 
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’any-second-exprl>)  & 

Def ine-Tree-Attributes ( ’ Composition-Expr ,  { ’ any-one-expr 1 , 

'any-second-exprl})  & 

Define-Tree-Attributes( ’BackCompose-Expr,  {’any-one-exprl, 

’any-second-exprl})  & 

Define-Tree-Attributes( ’OverRiding-Expr ,  {’any-one-exprl, 

’any-second-exprl})  & 

Def ine-Tree-Attributes ( ’DomainRes-Expr ,  { ’ any-one-exprl , 

’any-second-exprl})  & 

Def ine-Tree-Attributes(’RangeRes-Expr,  {’any-one-exprl, 

’any-second-exprl})  & 

Def ine-Tree-Attributes (’Ant iDomRes-Expr,  {’any-one-exprl , 

’any-second-exprl})  & 

Def ine-Tree-Attributes( ’AntiRangeres-Expr,  {’any-one-exprl, 

’any-second-exprl})  & 

Define-Tree-AttributesC’MonEmpty-Expr,  {’any-expr3})  & 
Define-Tree-Attributes(’IdRelation-Expr,  {’any-expr3})  & 

Def ine-Tree-Attributes( ’FiniteSet-Expr ,  {’any-expr3})  & 
Define-Tree-Attributes( ’NEFinite-Expr ,  {’any-expr3})  & 

Def ine-Tree-Attributes( ’Sequence-Expr,  {’any-expr3})  & 

Def ine-Tree-Attributes( ’NESeq-Expr ,  {’any-expr3})  & 
Define-Tree-Attributes(’InjSeq-Expr,  {’any-expr3})  & 
Define-Tree-Attributes( ’Z-Bag-Expr,  {’any-expr3})  & 

Define-Tree-Attributes( ’Inversion-Expr,  {’any-expr3})  & 
Define-Tree-Attributes( ’TransClosure-Expr ,  {’any-expr3})  & 
Define-Tree-Attributes( ’RefClosure-Expr ,  {’any-expr3}) 
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Appendix  I.  REFINE  Code  for  the  UZed  Grammar 


This  appendix  contains  the  REFINE  code  for  the  U^ed  grammar.  The  grammar 
uses  the  unified  domain  model  and  the  U.2ed  extensions  (found  in  Appendices  E  and  H) 
to  construct  its  production  rules.  This  grammar  uses  the  same  common  core  objects 
and  attributes  as  the  ULarch  grammar  to  promote  the  notion  of  language  inheritance. 
The  production  rules  demonstrate  Dialect’s  use  of  object  classes  and  attributes  to  form 
grammar  rules.  This  approach  is  more  intuitive,  thereby  simplifying  a  developer’s  task  for 
forming  tokens  and  creating  a  hierarchical  structure  for  a  formal  language. 


1. 1  UZed  Grammar 

! !  in-package ("RU") 

!!  in-grammar ( ’user) 

#1  I 

File  name:  uzed-gram.re 
Description; 

The  following  specification  defines  the  Core  Z  Grammar.  The  grammar 

uses  the  unified  domain  model  and  the  UZed  extensions  to  construct 

its  production  rules.  The  grammar  incorporates  LaTeX  specific  notations. 

I  I# 


5^ - 

7, - Uzed  Language  Grammar 

7 - 


!!  in-grammar ( ’syntax) 
grammar  Uzed 

start-classes  DomainTheory 
file-classes  DomainTheory 
no-patterns 

comments  matching  " 

II 

case-sensitive 

sjrmbol-continue-chcirs 

"abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMN0PqRSTUVWXYZ0123456789_{} [] - | \+-=<>" 
symbol-start-chars 

" abcdef ghi j  klmnopqrstuvwxyzABCDEFGHI JKLMNOPQRSTUVWXYZ_\<> " 
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productions 

DomainTheory 

ObjectTheory 

StateTheory 

EventTheory 

FunctionalTheory 

BasicTypesDefinition 
Dat aType  sDef init ion 
AxiomaticDefinition 
GenericDef init ion 
S  chemaExpr e  s  s i ons 
GlobalConst  ant  s 

Ob j  ectTheoryBody 

StateTheoryBody 

EventTheoryBody 

FunctionalTheoryBody 


:=  ["Wdocumentstyle  [fullpage  ,zed]  {article}" 
"\\begin{document}"  theory-types  +  "\\\\" 
"\\end{docuinent}"]  builds  DomainTheory, 

:=  ["\\begin{schema}{"ot-id"}"/, ObjectTheory" 

ot-body] 

builds  ObjectTheory, 

:=  ["\\begin{schema}{"st-id"}'/,StateTheory" 
st-body] 

builds  StateTheory, 

:=  ["\\begin{schema}{"et-id"}‘/,EventTheory" 
et-body] 

builds  EventTheory, 

:=  ["\\begin{schema>{"ft-id">*/, FunctionalTheory" 

ft-body] 

builds  FunctionalTheory, 


[zed-environ]  builds  BasicTypesDefinition, 
[syntax-environ]  builds  Dat aType sDef init ion, 
[axiomatic-box]  builds  AxiomaticDefinition, 
[generic-box]  builds  GenericDef inition, 
[schema-exp-def]  builds  SchemaExpressions , 
[constant-construct]  builds  GlobalConstants , 


[obj-theory-decl  {  [obj -theory-axioms] } 
"\\end{schema}"] 
builds  Obj ectTheoryBody, 

[state-theory-decl  { [state-theory-axioms] } 
"\\end{schema}"] 
builds  StateTheoryBody, 

[{ [event-theory-decl] }  event-theory-axioms 
" \\end{schema} " ] 
builds  EventTheoryBody, 

[fun-theory-decl  { [fun-theory-axioms] } 
"\\end{schema}"] 
builds  FunctionalTheoryBody, 


1-2 


ZedEnviron 

["\\begin{zed>"  " ["  i-dents  +  "] " 

"\\end{zed>"] 
builds  ZedEnviron, 

SyntaxEnviron 

C"\\begin{syntax}"  i-dent  {["&"]} 

{["&"]}  enums  ++ 

{["Walso"  i-dent  enums  ++ 

"\\end{ syntax}"] 
builds  SyntaxEnviron, 

AxiomaticBox 

1  J  — 

[" \\begin{axdef > "  axiom-de  cl-part 
{ [axiom-axiom-part] }  "\\end{axdef }"] 
builds  AxiomaticBox, 

GenericBox 

[" \\begin{gendef } " 

{["\\["  para-list  +  "\\]"]> 

generic-decl-part  { [generic-axiom-part] } 
"\\end{gendef}"] 
builds  GenericBox, 

SchemaExpDef 

:  :  = 

[theory-id  ■[ [gen-formal s  +  ","]} 

"Wdefs"  schema-exp] 
builds  SchemaExpDef, 

ConstantConstruct 

:  :  = 

[defs-lhs  "=="  any-expr] 
builds  ConstantConstruct, 

AxiomaticDefDecl 

1 1  = 

[axiom-decls  +  "\\\\" 

{["Walso"  schema-inclusion  +  "\\\\"]}] 
builds  Axiomat icDefDecl, 

AxioraaticDef Axioms 

:  :  = 

["Wwhere"  any-axiom-preds  +  "\\\\"] 
builds  AxiomaticDef Axioms , 

GenericDefDecl 

:  :  = 

[basic-decls  +  "\\\\" 

{["Walso"  schema-inclusion  +  "WW"]}] 
builds  GenericDefDecl, 

GenericDef Axioms 

:  :  = 

["Wwhere"  any-preds  +  "WW"] 
builds  GenericDef Axioms , 

ObjectTheoryDecl 

1 1~ 

[object-decls  +  "WW" 

{["Walso"  schema-inherit  +  "WW"]}] 
builds  ObjectTheoryDecl, 

Ob j  e  ctThe  oryAxioms 

:  :  = 

["Wwhere"  any-object-preds  +  "WW"] 
builds  ObjectTheoryAxioms , 

StateTheoryDecl 

:  :  = 

[schema- inclusion  +  "WW" 

{[state-decls  +  "WW"]}] 
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builds  StateTheoryDecl, 


StateTheory Axioms 

["Wwhere"  any-state-preds  +  "\\\\" 

{["Walso"  state-post-preds  +  "\\\\"]}] 
builds  StateTheoryAxioms, 

EventTheoryDecll 

:  ;  = 

[one-event-decl]  builds  EventTheoryDecll, 

EventTheoryDecl2 

:  :  = 

[event-decls  ++  "\\\\"]  builds  EventTheoryDecl2 , 

EventTheoryAxioms 

:  :  = 

["Wwhere"  any-event-preds  +  "\\\\"] 
builds  EventTheoryAxioms , 

Funct i onalThe  or yDe  c 1 

r  I  — 

[any-schema2-refs  +  "\\\\"  "\\\\" 
{[functional-decls  +  "WW"]}] 
builds  FunctionalTheoryDecl, 

FunctionalTheoryAxioms 

I ;  — 

["Wwhere"  any-fun-preds  +  "WW" 

{["Walso"  fun-post-preds  +  "WW"]}] 
builds  FunctionalTheoryAxioms , 

Def-Lhsl 

1 1  ~ 

[def-var-name 

■C["W["  gen-para-list  +  "W]"]}] 

builds  Def-Lhsl, 

SchemaText 

:  ;  = 

[basic-decls  +  " ; "  { [  " I "  any-pred] >] 
builds  SchemaText, 

SchemaRef 

:  :  = 

[schema-name]  builds  SchemaRef, 

Unde  c  or at  e  dS  chema 

:  :  = 

[theory-id]  builds  UndecoratedSchema, 

DecoratedSchema 

:  :  = 

[theory-id  any-decs  +  ""]  builds  DecoratedSchema 

DeltaSchema 

:  :  = 

["WDelta"  theory-id]  builds  DeltaSchema, 

XiSchema 

:  :  = 

["WXi"  theory-id]  builds  XiSchema, 

BasicDeclSeq 

:  :  = 

[basic-i-dents  +  " , "  " : "  any-expr] 
builds  BasicDeclSeq, 

Identifier 

:  :  = 

[i-dent  {any-decoration}]  builds  Identifier, 

InFixOperation 

:  :  = 

[marker 1  any-in-f ix-sym  marker2] 
builds  InFixOperation, 

ImageOperation 

:  :  = 

[markerl  "Wlimg"  marker2  "Wrimg"] 
builds  ImageOperation, 

IdName 

;  ;  = 

[name]  builds  IdName, 
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Numl 

:  :  = 

[num-1]  builds  Ntiml, 

Num2 

:  :  = 

[num-2]  builds  Num2, 

Final-Decoration 

:  :  = 

[","] 

builds  Final-Decoration, 

Input-Decoration 

:  :  = 

["?"] 

builds  Input-Decoration, 

Output-Decoration 

:  :  = 

["!"] 

builds  Output-Decoration 

MarkerSymbol 

:  :  = 

["_"] 

builds  MarkerSymbol, 

Equality 

:  :  = 

["="] 

builds  Equality, 

ElementOf 

;  ;  = 

["Win"]  builds  ElementOf, 

I - 

‘/,y,  Syntax  for  Schema  Calculus  Expressions 

I - 

Universal-SchemaExp  ::=  ["\\forall"  schema-text  "Wspot"  any-schema-exp] 

builds  Universal-SchemaExp, 

Existential-SchemaExp  :  :=  ["Wexists"  schema-text  "Wspot"  any-schema-exp] 

builds  Existential-SchemaExp, 

Unique -SchemaExp  ::=  ["\\exists_l"  schema-text  "Wspot"  any-schema-exp] 

builds  Unique - S  chemaExp , 

SchemaText-SchemaExp  : :=  ["["  schema-text  "] "] 

builds  SchemaText-SchemaExp, 

SchemaRef-SchemaExp  : ;=  [schema-ref] 

builds  SchemaRef-SchemaExp, 

Negated-SchemaExp  ::=  ["Wlnot"  any-schema-expl] 

builds  Negated-SchemaExp, 

PreCondition-SchemaExp  : :=  ["Wpre"  any-schema-expl] 

builds  PreCondition-SchemaExp, 

Conjunct-SchemaExp  :  :=  ["("  anyl-schema-expl  "Wland" 

any2-schema-expl  ")"] 
builds  Conjunct-SchemaExp, 

Disjunct-SchemaExp  :  :=  ["("  anyl-schema-expl  "Wlor" 

any2-schema-expl  ")"] 
builds  Disjunct-SchemaExp, 

Implication-SchemaExp  : :=  ["("  anyl-schema-expl  "Wimplies" 
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aiiy2-schema-expl  ")"] 
builds  Implication-SchemaExp, 


Equivalent -S  chemaExp 

["("  anyl-scheraa-expl  "\\iff" 
any2-schema-expl  ")"] 
builds  Equivalent-SchemaExp, 

Projection-SchemaExp 

1  1  — 

["("  anyl-schema-expl  "Wproject" 
any2-schema-expl  ")"] 
builds  Projection-SchemaExp, 

Hiding- S  chemaExp 

1  I  — 

["("  any-schema-expl  "\\hide" 

basic-i-dents  +  ")"  ")"] 

builds  Hiding-S chemaExp, 

Composition-SchemaExp 

["("  anyl-schema-expl  "Wsemi" 
any2-schema-expl  ")"] 
builds  Composition-SchemaExp, 

i‘/o  Syntax  for  Predicates 

Universal-Pred 

:  ;  = 

["Wforall"  schema-text  "\\spot"  any-pred] 
builds  Universal-Pred, 

Exist ential-Pred 

:  :  = 

["Wexists"  schema-text  "Wspot"  any-pred] 
builds  Existential-Pred, 

Unique-Pred 

:  :  = 

["\\exists_l"  schema-text  "Wspot"  any-pred] 
builds  Unique-Pred, 

True-Pred 

:  :  = 

["True"]  builds  True-Pred, 

False-Pred 

:  :  = 

["False"]  builds  False-Pred, 

Negated-Pred 

:  :  = 

["Wlnot"  any-predl]  builds  Negated-Pred, 

Conjunct-Pred 

:  :  = 

["("  anyl-predl  "\\land"  any2-predl  ")"] 
builds  Conjunct-Pred, 

Disjunct-Pred 

:  :  = 

["("  cuiyl-predl  "\\lor"  any2-predl  ")"] 
builds  Disjunct-Pred, 

Implication-Pred 

:  :  = 

["("  anyl-predl  "Wimplies"  any2-predl  ")"] 
builds  Implication-Pred, 

Equivalent-Pred 

:  :  = 

["("  anyl-predl  "\\iff"  any2-predl  ")"] 
builds  Equivalent-Pred, 
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Re 1 at i onal 1 -Pr e d 


Relational2-Pred 


Relational3-Pred 


SchemaRef-Pred 

PreSchemaRef-Pred 


Bracket-Pred 


[any-one-expr  anyl-in-rel-sym  any-second-expr] 
builds  Relationall-Pred, 

[any-one-expr  anyl-in-rel-sym  any-second-expr 
any2-in-rel-sym  any-third-expr] 
builds  Relational2-Pred, 

[any-one-expr  anyl-in-rel-sym  any-second-expr 
any2-in-rel-sym  any-third-expr 
any3-in-rel-sym  any-f ourth-expr] 
builds  Relational3-Pred, 

[schema-ref]  builds  SchemaRef-Pred, 

["\\pre"  schema-ref] 
builds  PreSchemaRef-Pred, 

["("  any-pred  ")"]  builds  Bracket-Pred, 


I - 

VI.  Syntax  for  Expressions 

I - 


Lambda-Expr 

*  •  “ 

["Wlambda"  schema-text  "\\spot"  any-expr] 
builds  Lambda-Expr, 

Mu-Expr 

:  :  = 

["\\mu"  schema-text  {["Wspot"  any-expr]}] 
builds  Mu-Expr, 

Cart e  s ianProd-Expr 

:  :  = 

[any-exprsl  ++  "\\cross"] 
builds  CartesianProd-Expr , 

Natural-Type 

; :  = 

["Wnat"]  builds  Natural-Type, 

Positive-Type 

:  :  = 

["\\nat_l"]  builds  Positive-Type, 

Integer-Type 

:  :  = 

["\\num"]  builds  Integer-Type, 

Real-Type 

:  :  = 

["Weal  R"]  builds  Real-Type, 

Character-Type 

; ;  = 

["Wseq  CHAR"]  builds  Character-Type, 

Power Set -Expr 

:  :  = 

["Wpower"  any-expr3]  builds  PowerSet-Expr , 

Negative-Expr 

:  :  = 

["-"  cuiy-expr3]  builds  Negative-Expr, 

Exponent -Expr 

:  :  = 

[ciny-exprS  "\\bsup"  any-expr  "\\esup"] 
builds  Exponent -Expr , 

Re 1 Image -Expr 

:  :  = 

[any-expr3  "\\limg"  any-exprO  "\\rimg"] 
builds  Rellmage-Expr , 

FunctionApp-Expr 

;  :  = 

[any-expr2  any-expr 3]  builds  FunctionApp-Expr, 
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Var-Name-Expr  :  :=  [var-name  {["\\["  gen-actual-list  +  "W]"]}] 

builds  Var-Mame-Expr , 

Op-Name-Expr  ::=  ["("  any-op-name  ")"]  builds  Op-Name-Expr , 

Integer-Expr  ::=  [num-1]  builds  Integer-Expr , 

Real-Expr  ::=  [num-2]  builds  Real-Expr, 

Set-Display-Expr  : ;=  ["\\{"  any-exprs  ♦  "\\>"] 

builds  Set-Display-Expr, 

Set-Comp-Expr  ::=  ["\\{"  set-schema-text 

{["Wspot"  any-expr]}  "\\}"] 
builds  Set-Comp-Expr, 

Seq-Expr  ::=  ["\\langle"  any-exprs  *  "Wrangle"] 

builds  Seq-Expr, 

Bag-Expr  :  :=  ["\\lbag"  any-exprs  *  "Wrbag"] 

builds  Bag-Expr, 

Tuple-Expr  ::=  ["("  any-exprs  ++  ","  ")"]  builds  Tuple-Expr, 

Theta-Expr  ;  :=  ["Wtheta"  theory-id  deco-ration] 

builds  Theta-Expr, 

Component -Expr  : :=  [any-expr3  i-dent]  builds  Component-Expr 


precedence 

for  schemaexp  brackets  "("  matching  ")" 

(same-level  "\\\\",  associativity  left), 
(scirae-level  "\\serai"  associativity  left), 
(same-level  "Whide"  associativity  left), 
(same-level  "Wproject"  associativity  left), 
(same-level  "\\iff"  associativity  left), 
(same-level  "Wimplies"  associativity  right) , 
(same-level  "\\lor"  associativity  left), 
(same-level  "Wland"  associativity  left), 
(same-level  "\\pre"  associativity  none), 
(same-level  "\\lnot"  associativity  none) , 
(same-level  "=",  "Win"  associativity  none) , 
(same-level  "Wcross"  associativity  left), 
(same-level  "Wpower"  associativity  right) 

end 
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1.2  UToolKit  Grammar 


! !  in-package ("RU") 

!!  in-grammar (’user) 

#1  I 

File  name:  utoolkit-gram.re 
Description: 

The  following  specification  defines  the  Unified  Mathematical  ToolKit  Grammar. 
The  grammar  uses  the  unified  domain  model  and  the  UZed  extensions  to 
construct  its  production  rules.  The  grammar  incorporates  LaTeX  specific 
notations. 

II# 


! !  in-grammar ( ’ syntax) 

grammar  UToolKit 

inherits-from  Uzed 
start-classes  DomainTheory 

file-classes  DomainTheory 
no-patterns 

comments  matching  " 

II 

case-sensitive 

symbol-continue-chars 

"abcdef ghi jklmnopqrstuvwxyzABCDEFGHIJKLMN0PQRSTUVWXYZ0123456789_{> [] - | \+-=<>" 
symbol-start-chars 

"abcdef ghi jklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ_\<>" 


productions 

PreFixOperation  : :=  [any-pre-f ix-sym  marker 1] 

builds  PreFixOperation, 

PostFixOperation  : :=  [markerl  any-post-f ix-sym] 

builds  PostFixOperation, 


•/. - 

*/,'/,  MiscSymbols 

I - 


m  SetAlgebra 

PairFirst 

PairSecond 

EmptySet 


["first"]  builds  PairFirst, 
["second"]  builds  PairSecond, 
["Wempty"]  builds  EmptySet, 


GeneralUnion 

Generalintersect 


["Wbigcup"]  builds  GeneralUnion, 
["Wbigcap"]  builds  Generalintersect, 


Relations 

RelDomain 

RelRange 

y, Functions 

y,y,y,  Numbers 

Successor 

Cardinality 

Minimum 

Maximum 

VIX  Sequences 

HeadSeq 

LastSeq 

TailSeq 

FrontSeq 

y.y.y,  Bags 

BagCoiint 

Bagitems 

I - 

y,y,  InRelSymbols 

y. - 

NotEquality 

NotElementOf 

Z-Subset 

PropSubset 

LessThan 

GreaterThan 

LessThanEq 

GreaterThanEq 

Partition 

InBag 


["\\dom"]  builds  RelDomain, 
["\\ran"]  builds  RelRange, 


["Wsucc"]  builds  Successor, 
["\\#"]  builds  Cardinality, 
["\\min"]  builds  Minimum, 
["\\max"]  builds  Maximum, 


["head"]  builds  HeadSeq, 
["last"]  builds  LastSeq, 
["tail"]  builds  TailSeq, 
["front"]  builds  FrontSeq, 


["count"]  builds  BagCount, 
["items"]  builds  Bagitems, 


["\\neq"]  builds  NotEquality, 
["Wnotin"]  builds  NotElementOf, 
["Wsubset"]  builds  Z-Subset, 
["Wsubseteq"]  builds  PropSubset, 
["<"]  builds  LessThan, 

[">"]  builds  GreaterThcUi, 
["\\leq"]  builds  LessThanEq, 
["Wgeq"]  builds  GreaterThanEq, 
["Wpartition"]  builds  Partition, 
["Winbag"]  builds  InBag, 


I - 

y,y,  PreRelSymbols 

I - 

DisjointSet  :  :=  ["Wdisjoint"]  builds  DisjointSet, 


t - 

y,y,  InGenSymbols 

I - 


I-IO 


Relation 

Z-Function 

PartialFun 

Injection 

Partialinject 

Surjection 

PartialSurject 

Bijection 

F init  ePartFun 

Finit  ePart In j  e  ct 


["\\rel"]  builds  Relation, 

["Wfun"]  builds  Z-Function, 
["Wpfun"]  builds  PartialFun, 
["\\inj"]  builds  Injection, 
["Wpinj"]  builds  Partialinject, 
["Wsurj"]  builds  Surjection, 
["Wpsurj"]  builds  PartialSurject, 
["\\bij"]  builds  Bijection, 
["Wffun"]  builds  Finit  ePartFun, 
["Wfinj"]  builds  FinitePartInject , 


I - 

%’/,  InFunSymbols 

I - 

Mapping 

NumRange 

Addition 

Subtraction 

SetUnion 

SetMinus 

Concatenation 

BagUnion 

Multiplication 

Division 

Modulo 

Setintersect 

Filtering 

Composition 

BackCompose 

OverRiding 

DomainRes 

RangeRes 

AntiDomRes 

AntiRangeRes 


["Wmapsto"]  builds  Mapping, 
["Wupto"]  builds  NumRange, 

[“+"]  builds  Addition, 

builds  Subtraction, 
["\\cup"]  builds  SetUnion, 
["Wsetminus"]  builds  SetMinus, 
["Wcat"]  builds  Concatenation, 
["Wuplus"]  builds  BagUnion, 
["*"]  builds  Multiplication, 
["Wdiv"]  builds  Division, 
["Wmod"]  builds  Modulo, 
["\\cap"]  builds  Setintersect, 
["Wfilter"]  builds  Filtering, 
["\\comp"3  builds  Composition, 
["Wcirc"]  builds  BackCompose, 
["Woplus"]  builds  OverRiding, 
["Wdres"]  builds  DomainRes, 
["Wrres"]  builds  RangeRes, 
["Wndres"]  builds  AntiDomRes, 
["Wnrres"]  builds  AntiRangeRes, 


y,7o  PreGenSymbols 

% - 

NonEmpty 

IdRelation 

Finite Set 

NEFinite 

Sequence 

NESeq 

InjSeq 

Z-Bag 


["\\power_l"]  builds  NonEmpty, 
["\\id"]  builds  IdRelation, 
["\\f inset"]  builds  FiniteSet, 
["\\f inset_l"]  builds  NEFinite, 
["\\seq"]  builds  Sequence, 
["\\seq_l"]  builds  NESeq, 
["Wiseq"]  builds  InjSeq, 
["\\bag"]  builds  Z-Bag, 


% - 

“/,*/,  PostFunSymbols 

% - 

Inversion  : :=  ["\\inv"]  builds  Inversion, 


I-ll 


TransClosure 
RefClosure 
y,  Iteration 


["Wplus"]  builds  TransClosure, 
["Wstar"]  builds  RefClosure, 

["Wbsup"  "n"  "Wesup"]  builds  Iteration, 


I - 

7,  Syntax  for  Predicates  &  Expressions 

I - 

y.y,  Syntax  for  PreRel-Predicates 

DisjointSet-Pred  : :=  ["\\dis joint"  any-expr] 

builds  DisjointSet-Pred, 


I - 

y.  Syntax  for  Misc-Expressions 

I - 


EmptySet-Expr 

•  \  — 

["\\{\\enipty\\}"]  builds  EmptySet-Expr , 

RelDomain-Expr 

:  ;  = 

["\\dom"  any-expr]  builds 

RelDomain-Expr , 

RelRange-Expr 

:  :  = 

["\\ran"  any-expr]  builds  RelRange-Expr , 

Cardinal ity-Expr 

:  :  = 

["\\#"  any-expr]  builds  Cardinality-Expr , 

,y,  Syntax  for  InGen-Expre 

ssions 

Relation-Expr 

:  :  = 

["("  any-one-expr  "Wrel" 
builds  Relation-Expr, 

any-second-expr  ")"] 

Z-Fvinction-Expr 

:  :  = 

["("  any-one-expr  "\\fun" 
builds  Z-Function-Expr , 

any-second-expr  ")"] 

Part ialFun-Expr 

:  :  = 

["("  any-one-expr  "Wpfun" 
builds  PartialFun-Expr , 

cuiy-second-expr  ")"] 

Injection-Expr 

:  :  = 

["("  any-one-expr  "\\inj" 
builds  Injection-Expr, 

any-second-expr  ")"] 

Partiallnj  ect-Expr 

:  :  = 

["("  any-one-expr  "Wpinj"  any-second-expr") "  ] 
builds  Partiallnj ect-Expr , 

Surjection-Expr 

:  :  = 

["("  any-one-expr  "Wsurj" 
builds  Surjection-Expr, 

any-second-expr")"  ] 

PartialSurj ect-Expr 

:  :  = 

["("  any-one-expr  "Wpsurj"  any-second-expr")"  ] 
builds  PartialSurj ect-Expr , 

Bijection-Expr 

:  ;  = 

["("  any-one-expr  "\\bij" 
builds  Bijection-Expr, 

any-second-expr")"  ] 
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F init  ePart  Fun-Expr 


["("  any-one-expr  "Wffun"  any-second-expr") "  ] 
builds  FinitePartFun-Expr , 


FinitePartInject-Expr 

["("  any-one-expr  "\\finj"  any-second-expr")" 
builds  FinitePartInject-Expr, 

i  Syntax  for  InFun-Expre 

ssions 

Mapping-Expr 

:  :  = 

[any-one-exprl  "Wmapsto"  any-second-exprl] 
builds  Mapping-Expr, 

NumRange-Expr 

:  :  = 

[any-one-exprl  "Wupto"  any-second-exprl] 
builds  NumRange-Expr, 

Addition-Expr 

:  :  = 

[any-one-exprl  "+"  any-second-exprl] 
builds  Addition-Expr, 

Subtract ion-Expr 

:  :  = 

[any-one-exprl  "-"  any-second-exprl] 
builds  Subtraction-Expr , 

SetUnion-Expr 

:  ;  = 

[any-one-exprl  "\\cup"  any-second-exprl] 
builds  SetUnion-Expr , 

SetMinus-Expr 

= 

[any-one-exprl  "Wsetminus"  any-second-exprl] 
builds  SetMinus-Expr, 

Concat  enat ion-Expr 

:  :  = 

[any-one-exprl  "\\cat"  any-second-exprl] 
builds  Cone at enat ion-Expr, 

BagUnion-Expr 

*  4  = 

[any-one-exprl  "\\uplus"  any-second-exprl] 
builds  BagUnion-Expr , 

Mult iplicat ion-Expr 

1 1  ~ 

[any-one-exprl  any-second-exprl] 

builds  Multiplication-Expr , 

Division-Expr 

i  *  ~ 

[any-one-exprl  "\\div"  any-second-exprl] 
builds  Division-Expr, 

Modulo-Expr 

i :  = 

[any-one-exprl  "\\mod"  any-second-exprl] 
builds  Modulo-Expr, 

Set Inter sect -Expr 

i  = 

[any-one-exprl  "\\cap"  any-second-exprl] 
builds  Setintersect-Expr , 

Filtering-Expr 

1 1  = 

[any-one-exprl  "Wfilter"  any-second-exprl] 
builds  Filtering-Expr, 

Composit ion-Expr 

1 1  ~ 

[any-one-exprl  "\\comp"  any-second-exprl] 
builds  Composition-Expr , 

BackCompose-Expr 

*,  i  “ 

[any-one-exprl  "Weire"  any-second-exprl] 
builds  BackCompose-Expr , 

OverRiding-Expr 

1 1  — 

[any-one-exprl  "\\oplus"  any-second-exprl] 
builds  OverRiding-Expr , 

DomainRes-Expr 

1 1  = 

[any-one-exprl  "\\dres"  einy-second-exprl] 
builds  DomainRes-Expr, 

RangeRes-Expr 

:  :  = 

[any-one-exprl  "Wrres"  ciny-second-exprl] 
builds  RangeRes-Expr, 

AntiDomRes-Expr 

I  — 

[any-one-exprl  "\\ndres"  any-second-exprl] 
builds  AntiDomRes-Expr, 
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AntiRangeRes-Expr 

V  _ _ 

[ciny-one-exprl  "\\nrres"  any-second-exprl] 
builds  AntiRangeRes-Expr, 

/o  .  . 

%%  Syntax  for  PreGen-Expressions 

V _ 

/o 

NonEmpty-Expr  :  :  = 

IdRelation-Expr  : := 

FiniteSet-Expr  :  :  = 

NEFinite-Expr  :  :  = 

Sequence-Expr  ::= 

NESeq-Expr  : :  = 

InjSeq-Expr  :  :  = 

Z-Bag-Expr  : :  = 

•/  - - 

["\\power_l"  any-exprS]  builds  NonEmpty-Expr, 
["\\id"  any-exprS]  builds  IdRelation-Expr, 
["\\f inset"  any-exprS]  builds  FiniteSet-Expr , 
["\\finset_l"  any-exprS]  builds  NEFinite-Expr, 
["\\seq"  any-exprS]  builds  Sequence-Expr, 
["\\seq_l"  any-exprS]  builds  NESeq-Expr, 
["Wiseq"  any-exprS]  builds  InjSeq-Expr, 
["\\bag"  any-exprS]  builds  Z-Bag-Expr, 

y.y,  Syntax  for  PostFun-Expressions 

Inversion-Expr  : :=  [ainy-exprS  "\\inv"]  builds  Inversion-Expr , 

TransClosure-Expr  : :=  [any-expr3  "Wplus"]  builds  TransClosure-Expr , 

RefClosure-Expr  :;=  [any-exprS  "\\star"]  builds  RefClosure-Expr 

y.  Iteration  ::=  [any-exprS  "\\bsup"  "n"  "Wesup"]  builds  Iteration, 

precedence 

for  expression  brackets  "("  matching  ")" 

(same-level  "\\\\",  associativity  left), 

(same-level  "\\dom"  associativity  right), 

(same-level  "\\#"  associativity  right), 

(same-level  "<",  "\\leq",  "Wgeq",  ">",  "\\neq",  "Wnotin",  "Wsubset", 
"Wsubseteq" ,  "Wpeirtition" ,  "Winbag"  associativity  none), 
(same-level  "\\mapsto"  associativity  left), 

(same-level  "\\upto"  associativity  left), 

(same-level  "\\cup",  "\\setminus" ,  "\\cat",  "Wuplus" 

associativity  left), 

(same-level  "\\div",  "\\mod",  "Wcap",  "\\comp",  "\\circ",  "Wfilter" 

associativity  left), 

(same-level  "Woplus"  associativity  left), 

(same-level  "\\dres",  "\\rres",  "Wndres",  "\\nrres"  associativity  left) 

end 
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Appendix  J.  Semantic  Analysis  Code 


This  appendix  contains  the  Rbfine  code  for  the  UZed  semantic  analysis  tasks.  These 
tasks  augment  the  ASTs  through  the  expansion  of  shorthand  notations,  and  complete  the 
intermediate  representation  prior  to  execution.  There  are  currently  five  completed  semantic 
analysis  tasks,  all  detailed  in  the  sections  below. 
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J.l  Schema  Inclusion 


!!  in-package("RU") 

!!  in-grammar ('user) 

#1  I 

File  name:  u-sch.ema- inclusion. re 
Description: 

The  following  Refine  program  traverses  a  UZed  AST  and  then  augments  the  tree 

with  any  included  schemas  by  merging  the  signatures  and  conjuncting  the  predicates  of  the  include< 

I  I# 

function  make-schema-inclusionO  = 

let  (Temp-Basic-Seq  :  BasicDeclSeq  =  make-object(’BasicDeclSeq)) 
let  (specs  :  set(DomainTheoryTypes)  = 

instances(f ind-object-class( ’DomainTheoryTypes) ,  true)) 
let  (Temp-Symbol  :  Symbol  =  newsymbol(’TempSymbol)) 
let  (Temp-Predicate  :  Predicate  =  mcike-object( ’Predicate)) 

(enumerate  zs  over  specs  do 

if (defined?  (st-body(zs) ) )  then 

(enumerate  i  over  descendants-of-class(st-body(zs) ,  ’UndecoratedSchema)  do 
(eniamerate  j  over  descendants-of-class(i,  ’IdName)  do 
(Temp-Symbol  <-  name(j); 
enumerate  k  over  specs  do 
(if  (Temp-Symbol  =  name(ot-id(k)))  then 
(enumerate  1  over  descendants-of-class(ot-body(k) ,  ’BasicDeclSeq)  do 
(Temp-Basic-Seq  <-  1; 

set-attrs( (Temp-Basic-Seq) ,  ’inclusion-link,  true); 
state-decls(state-theory-decl(st-body(zs)) )  <- 
state-decls(state-theory-decl(st-body(zs)))  with 
Temp-Basic-Seq 
) 

): 

(enumerate  m  over  descendants-of-class(ot-body(k) ,  ’Predicate)  do 
(Temp-Predicate  <-  m; 

state-post-preds(state-theory-axioms(st-body(zs)))  <- 

state-post-preds(state-theory-axioms(st-body(zs) ))  with 
Temp-Predicate 
) 

) 

) 

) 

) 

) 

'  ) 
tl 
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J.2  A  Notation  Expansion 


!!  in-package ("RU") 

!!  in-grammar ('user) 

#1  I 

File  name:  u-delta-schemas .re 

Description:  A  Delta  reference  is  expanded  by  unioning  the  signature  of  the 
Delta  schema  with  the  signature  of  the  referenced  schema.  Likewise,  the 
predicates  of  both  schemas  are  conjuncted  together.  A  boolean  annotation 
attribure,  “delta-link'',  is  set  to  true. 

I  I# 

function  make-delta-schemas  ()  = 

let  (Temp-Basic-Seq  :  BasicDeclSeq  =  make-object('BasicDeclSeq)) 
let  (specs  :  set (DomainTheoryTypes)  = 

instcinces (find-object-class ( 'DomainTheoryTypes) ,  true)) 
let  (Temp-Symbol  :  Symbol  =  newsymbol('TempSymbol)) 
let  (Temp-Predicate  :  Predicate  =  mcike-object('Predicate)) 

(enumerate  zs  over  specs  do 

if (defined?  (ft-body(zs)))  then 

(enumerate  i  over  descendants-of-class(ft-body(zs) ,  'DeltaSchema)  do 
(enumerate  j  over  descendants-of-class(i,  'IdName)  do 
(Temp-Symbol  <-  name(j); 
enumerate  k  over  specs  do 
(if  (Temp-Symbol  =  name(ot-id(k)))  then 
(enumerate  1  over  descendants-of-class(ot-body(k) ,  'BasicDeclSeq)  do 
(Temp-Basic-Seq  <-  1; 

set-attrs ( (Temp-Basic-Seq) ,  'delta-link,  true); 
functional-decls(fun-theory-decl(ft-body(zs) ) )  <- 
functional-decls(fun-theory-decl(ft-body(zs) ) )  with 
Temp-Basic-Seq 
) 

): 

(enumerate  m  over  descendants-of-class(ot-body (k) ,  'Predicate)  do 
(Temp-Predicate  <-  m; 

any-fun-preds (fun-theory-axioms (f t-body (zs) ) )  <- 

any-fun-preds(fun-theory-axioms(ft-body(zs)))  with 
Temp-Predicate 
) 

) 

) 

) 

) 

) 

) 

U 
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!  !  in-package ("RU") 
!!  in-grammar ( ’user) 


#11 

File  name:  u-delta-vars .re 


Description:  The  Delta  schema’s  signature  is  expanded  a  second  time  to 
include  the  ticked  counterparts  of  the  referenced  object’s  variables.  The 
predicate  is  expeinded  to  include  the  corresponding  constraints  placed  on  those 
ticked  variables. 

I  I# 


function  make-delta-vars 
let  (Temp-Identifier 
let  (specs 

let  (Temp-Idents 
let  (Temp-Expression 
let  (Temp-DeclSeq 


()  = 

:  Identifier  =  make-object (’Identifier)) 

:  set(DomainTheoryTypes)  = 

instances (find-object-class (’DomainTheoryTypes) , 
:  set (Identifier)  =  {}) 

:  Expression  =  make-object (’Expression)) 

:  BasicDeclSeq  =  make-object( ’BasicDeclSeq)) 


true)) 


(enumerate  zs  over  specs  do 

if (defined?  (ft-body(zs) ) )  then 

(eniunerate  i  over  descendants-of-class(ft-body(zs) ,  ’BasicDeclSeq)  do 
if (defined?  (delta-link(i)))  then 
(Temp-Idents  <-  {>; 

enmerate  j  over  descendants-of-class(i,  ’Identifier)  do 
Temp-Identifier  <- 
set-attrs (make-object (’Identifier) , 

’ i-dent , 

set-attrs(make-object(’IdName) , 

’Name,  name( i-dent ( j ))) , 

’ any-de c or at i on , 

(make-object  (’Final-Decoration))) ; 
Temp-Idents  <-  Temp-Idents  with  Temp-Identifier 
); 

(enumerate  k  over  descendants-of-class(i,  ’Expression)  do 
Temp-Expression  <-  k 
); 

Temp-DeclSeq  <-  set-attrs(make-object( ’BasicDeclSeq) , 

’basic-i-dents,  Temp-Idents, 
’any-expr,  Temp-Expression); 
functional-decls(fun-theory-decl(ft-body(zs)))  <- 
functional-decls(fun-theory-decl(ft-body(zs)))  with 
Temp-DeclSeq 

) 

) 
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J.3  H  Notation  Expansion 


!!  in-package ("RU") 

!!  in-grammar ( ’user) 

#11 

File  name:  u-xi-schemas.re 

Description:  A  Xi  reference  is  expeinded  by  unioning  the  signature  of  the 
Xi  schema  with  the  signature  of  the  referenced  schema.  Likewise,  the 
predicates  of  both  schemas  are  conjuncted  together.  A  boolean  annotation 
attribure,  ‘‘xi-link’’,  is  set  to  true. 

I  I# 

function  make-xi-schemas  ()  = 

let  (Temp-Basic-Seq  :  BasicDeclSeq  =  make-object(’BasicDeclSeq)) 
let  (specs  :  set(DomainTheoryTypes)  = 

instances (f ind-object-class( ’DomainTheoryTypes) ,  true)) 
let  (Temp-Symbol  :  Symbol  =  news3rmbol(’TempSymbol)) 
let  (Temp-Predicate  :  Predicate  =  make-object( ’Predicate) ) 

(enumerate  zs  over  specs  do 

if (defined?  (ft-body(zs) ) )  then 

(enumerate  i  over  descendants-of-class(ft-body(zs) ,  ’XiSchema)  do 
(enumerate  j  over  descendants-of-class(i,  ’IdName)  do 
(Temp-Symbol  <-  name(j); 
enumerate  k  over  specs  do 
(if  (Temp-Symbol  =  name(ot-id(k)))  then 
(enumerate  1  over  descendants-of-class(ot-body(k) ,  ’BasicDeclSeq)  do 
(Temp-Basic-Seq  <-  1; 

set-attrs ( (Temp-Basic-Seq) ,  ’xi-link,  true); 
functional-decls(fun-theory-decl(ft-body(zs)) )  <- 
functional-decls (f un-theory-decl (f t-body (zs) ) )  with 
Temp-Basic-Seq 
) 

): 

(enumerate  m  over  descendants-of-class(ot-body(k) ,  ’Predicate)  do 
(Temp-Predicate  <-  m; 

any-fun-preds (fun-theory-axioms (f t-body (zs) ) )  <- 

any-f un-preds (fun-theory-axioms (f t-body (zs ) ) )  with 
Temp-Predicate 
) 

) 

) 

) 

) 

) 

) 
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!  !  in-package ("RU") 
!!  in-graaimarC ’user) 


#11 

File  name:  u-xi-vars.re 


Description:  The  Xi  schema’s  signature  is  expanded  a  second  time  to 
include  the  ticked  counterparts  of  the  referenced  object’s  variables.  The 
predicate  is  expanded  to  include  the  corresponding  constraints  placed  on  those 
ticked  variables. 

II# 


function  make-xi-vars  () 
let  (Temp-Identifier 
let  (specs 

let  (Temp-Idents 
let  (Temp-Expression 
let  (Temp-DeclSeq 


:  Identifier  =  make-object (’Identifier)) 

:  set(DomainTheoryTypes)  = 

instances (find-object-class ( ’DomainTheoryTypes) , 
:  set (Identifier)  =  {}) 

:  Expression  =  make-object (’Expression)) 

:  BasicDeclSeq  =  make-object(’BasicDeclSeq)) 


true)) 


(enumerate  zs  over  specs  do 

if (defined?  (ft-body(zs) ) )  then 

(eniimerate  i  over  descendants-of-class(ft-body(zs) ,  ’BasicDeclSeq)  do 
if (defined?  (xi-link(i)))  then 
(Temp-Idents  <-  {}; 

eniimerate  j  over  descendants-of-class(i,  ’Identifier)  do 
Temp-Identifier  <- 
set-attrs (make-object (’Identifier) , 

’ i-dent , 

set-attrs(make-object(’IdName) , 

’Name,  name(i-dent(j))) , 

’ any-decoration , 

(racike-object  ( ’Final-Decoration) ) ) ; 
Temp-Idents  <-  Temp-Idents  with  Temp-Identifier 
); 

(enumerate  k  over  descendcints-of-class(i,  ’Expression)  do 
Temp-Expression  <-  k 
); 

Temp-DeclSeq  <-  set-attrs (make-object( ’BasicDeclSeq) , 

’basic-i-dents,  Temp-Idents, 
’any-expr,  Temp-Expression); 
functional-decls(fun-theory-decl(ft-body(zs)))  <- 
functional-decls(fun-theory-decl(ft-body(zs)))  with 
Temp-DeclSeq 

) 

) 
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Appendix  K.  Execution  Target  Domain  Model 


This  appendix  contains  the  object-oriented  domain  model  for  the  execution  frame¬ 
work.  Refine  is  the  target  framework,  and  the  following  figures  identify  the  principal 
object  classes.  This  model  guides  the  development  of  the  execution  framework  mappings 
providing  a  concrete  target  for  the  source  objects. 


Figure  K.l  Unified  Domain  Theory  Model 
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Appendix  L.  REFINE  Code  for  the  Target  Domain  Model 


The  following  Refine  specification  defines  the  object  classes  and  map  attributes  for 
the  execution  framework.  Because  the  target  execution  framework  is  REFINE,  the  code 
incorporates  the  notions  of  object  classes,  map  attributes,  functions,  and  rules,  as  the 
target  objects. 


!!  in-package ("RU") 

!!  in-grammar (’user) 

#1  I 

File  name:  exec. re 

Description:  The  following  program  defines  the  transform  rules  for  the  formal 
execution  model.  Refine  has  been  selected  as  the  target  execution  environment 
Therefore,  the  treinsforms  map  the  unified  domain  model  into  a  refine  execution 
model . 

II# 


I - 

%  Refine  Object  Class  Declaration 


:  object-class  subtype-of  user-object 
:  object-class  subtype-of  Refine-Object-Model 


var  Refine-Object-Model 
var  Refine-Declaration 


var  Ref ine-Decl-Attrs 

var  Ref ine-Annotation-Attr 
Vcir  Ref ine-Tree-Attr 
var  Ref ine-Decl-Obj-Class 


:  object-class  subtype-of  Refine-Object-Model 
:  object-class  subtype-of  Ref ine-Decl-Attrs 
:  object-class  subtype-of  Ref ine-Decl-Attrs 
:  object-class  subtype-of  Refine-Object-Model 


var  Refine-Function 
var  Refine-Function-Body 
var  Function-Parameters 
var  Parameter-Value 
var  Parameter-Type 
var  Function-Let-Statement 
var  Function-Transform 
var  Function-Precondition 
var  Function-Postcondition 


object-class 

object-class 

object-class 

object-class 

object-class 

object-class 

object-class 

object-class 

object-class 


subtype-of 

subtype-of 

subtype-of 

subtype-of 

subtype-of 

subtype-of 

subtype-of 

subtype-of 

subtype-of 


Refine-Object-Model 
Refine-Object-Model 
Refine-Object-Model 
Refine-Object-Model 
Refine-Object-Model 
Refine-Object-Model 
Refine-Object-Model 
Refine-Object-Model 
Ref ine-Obj ect -Model 


var  Refine-Rule 

var  Rule -Precondition 

var  Rule-Postcondition 


:  object-class 
:  object-class 
:  object-class 


subtype-of  Refine-Object-Model 
subtype-of  Refine-Object-Model 
subtype-of  Refine-Object-Model 
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% - 

*/,  Refine  Attribute  Declarations  for  Branches  in  Tree  Structure 
% - 


var  refineDecl 
var  refineObjClasses 

var  refineAttrs 

var  ref ineFunctions 

var  functionBody 
var  parameterList 

var  parameters 

var  parameterType 
var  letStatements 

var  transforms 

var  functionPre 

var  functionPost 

var  refineRules 
var  rulePre 
var  rulePost 


:  map(Refine-Object-Model,  Refine-Declaration)  =  {11} 

:  map(Refine-Qbject-Model,  set(Refine-Decl-Obj-Class)) 
computed-using  ref ineObjClasses(x)  =  {} 

:  mapCRef ine-Object-Model,  set(Refine-Decl-Attrs)) 

computed-using  ref ineAttrs(x)  =  {> 

:  map(Ref ine-Object-Model,  set (Refine-Function) ) 

computed-using  ref ineFunctions (x)  =  {} 

:  map (Ref ine-Object-Model,  Refine-Function-Body)  =  {||} 

:  map (Refine-Object-Model,  set (Function-Parameters)) 

computed-using  parameterList (x)  =  {} 

:  map (Function-Parameters,  set (Parameter-Value)) 

computed-using  parameters (x)  =  {} 

:  map(Function-Parameters ,  Parameter-Type)  =  {11} 

:  map (Refine-Object-Model,  set(Function-Let-Statement) ) 
computed-using  letStatements (x)  =  {} 

:  map (Refine-Object-Model,  set (Function-Transform)) 

computed-using  transforms (x)  =  {} 

;  map (Ref ine-Object-Model ,  set (Function-Precondition)) 
computed-using  functionPre (x)  =  {} 

:  map(Ref ine-Object-Model,  set (Function-Postcondition)) 
computed-using  functionPost (x)  =  {} 

:  map(Ref ine-Object-Model,  set (Refine-Rule)) 

computed-using  ref ineRules(x)  =  {} 

:  raap(Ref ine-Object-Model,  set (Rule-Precondition)) 

computed-using  rulePre(x)  =  {} 

:  map (Ref ine-Object-Model ,  set (Rule-Postcondition) ) 

computed-using  rulePost (x)  =  {} 


I - 

"/,  Annotation  Attributes  For  Object  Refine-Decl-Attrs 

I - 

{||} 
{||} 


var  attrDomain  :  map(Refine-Decl-Attrs,  symbol) 

var  attrCoDomain  :  map(Refine-Decl-Attrs,  symbol) 


I - 

y,  Declarations  for  other  Objects 

I - 

var  Exec-Program  :  Refine-Object-Model  =  make-object (’Refine-Object-Model) 
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I - 

'/,  Structure  for  Abstract  Syntax  Tree 
% - 


form  Def ine-Tree-Attributes-of-Refine-Rules 

Def ine-Tree-Attributes( 'Ref ine-Object-Model,  {'refineDecl,  'ref ineFunctions, 
'refineRules})& 

Def ine-Tree-Attributes( 'Ref ine-Declaration,  {'ref ineObj Classes, 

'ref ineAttrs})& 

Def ine-Tree-Attributes( 'Ref ine-Function,  {'parameterList ,  'functionBody})& 
Def ine-Tree-Attributes( 'Function-Parameters,  {'parameters ,  'parameterType})& 
Define-Tree-Attributes( 'Refine-Function-Body,  {'letStatements, 

' transforms} )& 

Define-Tree-Attributes( 'Function-Trauisform,  {'functionPre ,  'functionPost})& 
Def ine-Tree-Attributes( 'Ref ine-Rule ,  {'rulePre,  'rulePost}) 
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Appendix  M.  Refine  Code  for  the  Initial  Execution  Code 


The  following  Refine  program  creates  an  initial  framework  for  an  executable  pro¬ 
gram.  The  main  function,  Make-Executable,  encapsulates  the  Make-Object-Classes,  Make- 
Attributes,  and  Make-Punction  operations  generating  the  appropriate  object  classes  and 
attributes  in  the  execution  framework  from  the  source  objects.  After  creating  the  execu¬ 
tion  framework,  the  Print-Program  function  traverses  the  executable  AST  and  prints  an 
executable  program’s  initial  shell  consisting  of  the  object  classes,  map  attributes,  function 
names,  and  parameters. 


!!  in-package ("RU") 

!!  in-grammar ( ’user) 

#1  I 

File  name:  u-transform.re 

Description:  The  following  program  creates  the  initial  freunework  for  the  execution 
program.  The  print  function  prints  the  executable  program  consisting  of  object 
classes,  map  attributes  and  function  names. 

I  I# 

!!  in-package ("RU") 

!!  in-grammar ( ’user) 

function  make-object-class  (Temp-Specs  :  set(DomainTheoryTypes) , 

Temp-Decl  :  Refine-Declaration, 

Temp-Exec-Progrcim  :  Refine-Object-Model)  :  Refine-Object-Model  = 

let  (Refine-Object  :  Ref ine-Decl-Obj-Class  =  make-object(’Refine-Decl-Obj-Class)) 

(enumerate  tr  over  Temp-Specs  do 
(enumerate  o  over  descendcints-of-class(tr ,  ’ObjectTheory)  do 
Refine-Object  <-  set-attrs(make-object(’Refine-Decl-Obj-Class) , 

’Marne,  name(ot-id(o))) ; 

(format  (true,  "Refine-Object  "a"’/,",  Refine-Object)); 

ref ineObjClasses(Temp-Decl)  <-  ref ineObjClasses(Temp-Decl)  with  Refine-Object; 
(format  (true,  "programDecl  "a"'/,",  Temp-Decl)) 

) 

); 

refineDecl(Temp-Exec-Program)  <-  Temp-Decl; 

(format  (true,  "Exec-Program  "a"7,",  Temp-Exec-Program)) 
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:  set(DomainTheoryTypes) , 


fiinction  make-attributes  (Temp-Specs 
Temp-Decl  :  Refine-Declaration, 

Temp-Exec -Program  :  Refine-Object-Model)  :  Refine-Object-Model  = 

let  (Refine-Attr  :  Refine -Decl-Attrs  =  make-object(’Refine-Decl-Attrs)) 

(enumerate  tr  over  Temp-Specs  do 
(enumerate  o  over  descendcints-of-class(tr ,  ’ObjectTheory)  do 
(enumerate  a  over  descendants-of-class(o,  ’BasicDeclSeq)  do 
(format  (true,  "In  BasicdeclSeq  "a"7,",  a)); 

(enumerate  f  over  descendcints-of-class(a,  ’Identifier)  do 
(format  (true,  "In  Identifier  "a"*/,",  f)); 

Refine-Attr  <-  set-attrs(make-object( ’Ref ine-Decl-Attrs) , 

’Name,  name(i-dent(f ) ) , 

’attrDomain,  name(ot-id(tr)) , 

’attrCoDomain,  any-expr(a)) ; 

(format  (true,  "Refine-Attr  *a"7.",  Refine-Attr)); 
ref ineAttrs(Temp-Decl)  <-  ref ineAttrs (Temp-Decl)  with 
Refine-Attr ; 

(format  (true,  "programDecl  "a*7.",  Temp-Decl)) 

) 

) 

) 

); 

ref ineDecl (Temp-Exec-Program)  <-  Temp-Decl; 

(format  (true,  "Exec-Program  ''a''7«",  Temp-Exec-Program)) 


function  Make-Function  (Temp-Specs  :  set(DomainTheoryTypes) , 

Temp-Exec-Program  :  Refine-Object-Model)  :  Refine-Object-Model  = 

let  (Temp-Function  :  Refine-Function  =  make-object( ’Ref ine-Function)) 
let  (Temp-Set  :  set (Refine-Function)  =  {}) 

(enumerate  tr  over  Temp-Specs  do 
(enumerate  s  over  descendcLnts-of-class(tr ,  ’StateTheory)  do 
Temp-Set  <-  Temp-Set  with  (set-attrs(make-object( ’Ref ine-Function) , 

’Name,  name(st-id(s)))) 

); 

(enumerate  e  over  descendants-of-class(tr ,  ’EventTheory)  do 
Temp-Set  <-  Temp-Set  with  (set-attrs(make-object( ’Refine-Function) , 

’Name,  ncane(et-id(e)))) 

): 

(eniimerate  o  over  descendants-of-class(tr,  ’FunctionalTheory)  do 
Temp-Set  <-  Temp-Set  with  (set-attrs(make-object( ’Ref ine-Function) , 

’Name,  name(ft-id(o)))) 

) 

); 

ref ineFunctions (Temp-Exec-Program)  <-  ref ineFunctions (Temp-Exec-Program)  union  Temp-Set 
(format  (true,  "Exec-Program  "a"7«",  Temp-Exe c -Program) ) 
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function  Make-Executable  (theory  :  DomainTheory)  :  Refine-Object-Model  - 
let  (Specs  :  set(DomainTheoryTypes)  =  {}) 

let  (Temp-Exec-Program  :  Refine-Object-Model  =  make-object(’Refine-Object-Model)) 
let  (Program-Decl  :  Refine-Declaration  =  make-object ( ’Ref ine-Declaration) ) 

(enumerate  s  over  descendants-of-class (theory ,  ’DomainTheoryTypes)  do 
Specs  <-  Specs  with  s 
): 

(Make-Object-Class(Specs,  Program-Decl,  Temp-Exec-Program)); 

(Make-Attributes (Specs,  Program-Decl,  Temp-Exec-Program)); 

(Make-Function(Specs ,  Temp-Exec-Program) ) 

function  Print-Program  (program  :  object)  = 

undefined? (program)  — >  format(true,  "Nothing  to  print  "’/,"); 
defined? (program)  — > 

format  (true,  "!!  in-package (RU)  "7,"); 
format  (true,  "!!  in-grammar( ’user)  "7.  "7.  "7."); 

(enumerate  d  over  descendants-of-class(program,  ’Refine-Declaration)  do 
(enumerate  o  over  descendants-of-class(d,  ’Refine-Decl-Obj-Class)  do 

format  (true,  "7. - *A - 7.  "7.",  name(o)); 

format  (true,  "7. - '/•  '7»"); 

format (true,  "var  "A  :  object-class  subtype-of  user-object  *7.", 
name(o)) ; 

format(true,  "  "7.") 

): 

(enumerate  a  over  descendants-of-class(d,  ’Ref ine-Decl-Attrs)  do 

format(true,  "var  "A  :  map("A,  "A)  =  -CM}  "7.",  name(a),  attrDomain(a) , 
attrCoDomain(a) ) ; 
format  (true,  "  "7o") 

) 

); 

(enumerate  e  over  descendants-of-class(Program,  ’Refine-Function)  do 
format  (true,  "function  "A  ()  =  "7.",  name(e)) 

) 
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Appendix  N.  User’s  Manual  for  the  UZed  Parser 


This  appendix  contains  a  listing  of  the  Lisp  files  required  to  parse  Z  specifications. 
The  order  in  which  the  files  are  listed  below  indicates  the  required  compilation  order. 
Following  the  file  listings  is  a  set  of  instructions  guiding  a  user  through  a  sample  ses¬ 
sion  for  parsing  Z  specifications  and  viewing  the  corresponding  ASTs.  In  addition,  the 
final  instruction  shows  the  user  how  to  create  an  execution  framework  for  the  parsed  Z 
specifications. 


1.  Load  system  files  for  Dialect  and  Object  Inspector. 

(load  ' ‘load-inspector ' 

(load- inspect or) 

2.  Load  the  unified  Zed  domain  model  and  grammar  files  and 
the  target  execution  domain  model.  Bring  the  unified  Zed 
grammar  in  the  environment . 

(load  ‘‘uzed-dm’’) 

(load  ‘ ‘uzed-grara’ ’ ) 

(load  ‘ ‘utoolkit-dm’ ’ ) 

(load  ‘ ‘utoolkit-gram’ ') 

(in-grammar  ’UToolKit) 

(load  ‘ ‘ exec ’ ’ ) 

3.  Load  the  semantic  analysis  files. 

(load  ‘ ‘u-schema-inclusion’ ’ ) 

(load  ‘ ‘u-delta-schemas’ ’) 

(load  ‘ ‘ u-delta-vars ’ ’ ) 

(load  ‘ ‘u-xi- schemas ’’ ) 

(load  ‘ ‘u-xi-vars ’ ’ ) 

4.  Load  the  translation  program. 

(load  ‘ ‘u-transform’ ’) 

5.  Parse  your  domain  specification. 

*/,  C-x-i  u-counter.re  (for  counter  domain) 

’/,  C-x-i  u-fueltank.re  (for  fuel  tank  domain) 

'/,  C-x-i  u-passenger-list  .re  (for  aircraft  passenger  list  domain) 
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*/,  C-x-i  u-datadict  .re  (for  data  dictionary  domain) 

6.  View  the  initial  domain  specification  using  Object  Inspector. 

(pup)  ’/,  to  view  the  current  object; 

*/,  returns  the  magic  object  number. 

(insp;  :  inspect  (men  object’s  magic-number))  */,  brings  Object  Inspector  up 

'/,  with  the  current  object. 

7.  Execute  the  semantic  analysis  files  on  your  domain  specification 
to  bring  in  all  referenced  schemas. 

(make-schema- inclusion) 

(make-delta-schemas) 

(make-delta-vars) 

(make-xi-schemas) 

(make-xi-vars) 

8.  View  the  augmented  AST  using  Object  Inspector. 

(insp: : inspect-obj (men  object’s  magic-number)) 

9.  Execute  the  translation  function. 

(make-executable (men  domaintheory  object’s  magic  number)) 

(print-program  (men  executable  object’s  magic  number)) 

10.  Demo  Script  Sequence  (C-x-i  to  bring  domain  specifications  into  Refine) 

test  counter  domain  (”/thesis/compiler-code/uzed/valid-exaraples/u-counter.re) 
test  fueltank  domain  (~/thesis/compiler-code/uzed/valid-examples/u-fueltank.re) 
test  passenger  list  (~/thesis/compiler-code/uzed/valid-examples/u-passenger-list.re) 
test  data  dictionary  ("/thesis/compiler-code/uzed/valid-examples/u-datadict .re) 
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The  Refine  source  code  for  Z  and  U^ed  may  be  obtained,  upon  request,  from: 


Maj  Paul  Bailor 
AFIT/ENG 
2950  P  Street 

Wright-Patterson  AFB,  OH  45433-7765 

(513)255-9263 
DSN  785-9263 
email:  pbailor@afit.af.mil 
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